Identifying  Enterprise  Leverage  Points  in  Defense  Acquisition  Program 

Performance 

by 

Joseph  Robert  Wirthlin 

B.S.  Engineering  Sciences 
United  States  Air  Force  Academy,  1994 

S.M.  Engineering  and  Management 
Massachusetts  Institute  of  Technology,  2000 

Submitted  to  the  Engineering  Systems  Division  in  partial  fulfillment  of  the  requirements  for  the 

degree  of 

Doctor  of  Philosophy  in  Engineering  Systems 

at  the 


MASSACHUSETTS  INSTITUTE  OF  TECHNOLOGY 
September  2009 

©  2009  Joseph  Robert  Wirthlin.  All  rights  reserved. 

The  author  hereby  grants  to  MIT  permission  to  reproduce  and  to  distribute  publicly  paper  and 
electronic  copies  of  this  thesis  document  in  whole  or  in  part  in  any  medium  now  known  or 

hereafter  created. 


Signature  of  Author 


Engineering  Systems  Division 
September  05,  2009 


Certified  by. 


Warren  P.  Seering 

Weber-Shaughness  Professor  of  Mechanical  Engineering  and  Engineering  Systems 

Thesis  Supervisor 


Certified  by. 


Sheila  E.  Widnall 

Institute  Professor,  Aeronautics  and  Astronautics  and  Engineering  Systems 


Certified  by. 


Donald  R.  Lessard 

Epoch  Foundation  Professor  of  International  Management,  Sloan  School  of  Management 


Accepted  by . 

Nancy  Leveson 

Professor  of  Aeronautics  and  Astronautics  and  Engineering  Systems 

Chair,  ESD  Education  Committee 


1 


Report  Documentation  Page 


Form  Approved 
OMB  No.  0704-0188 


Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 


1.  REPORT  DATE 

SEP  2009 


2.  REPORT  TYPE 


3.  DATES  COVERED 

00-00-2009  to  00-00-2009 


5a.  CONTRACT  NUMBER 


5b.  GRANT  NUMBER 


5c.  PROGRAM  ELEMENT  NUMBER 


5d.  PROJECT  NUMBER 


5e.  TASK  NUMBER 


5f.  WORK  UNIT  NUMBER 


4.  TITLE  AND  SUBTITLE 

Identifying  Enterprise  Leverage  Points  in  Defense  Acquisition  Program 
Performance 

6.  AUTHOR(S) 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES)  8.  PERFORMING  ORGANIZATION 

Massachusetts  Institute  of  Technology, 77  Massachusetts  report  number 

Avenue, Cambridge, MA, 02139-4307 

9.  SPONSORING/MONITORING  AGENCY  NAME(S )  AND  ADDRESS(ES )  10.  SPONSOR/MONITOR' S  ACRONYM(S) 

11.  SPONSOR/MONITOR'S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

14.  ABSTRACT 

Large,  complex  systems  development  programs  in  the  Department  of  Defense  are  finding  it  more  difficult 
to  deliver  desired  capabilities  to  the  end  user  on  time  and  on  budget  than  ever  before.  Evidence  exists  that 
almost  all  developmental  programs  on  record  are  over  cost  and  schedule,  costing  the  Department  and 
ultimately  the  U.S.  taxpayer  billions  of  dollars  more  than  anticipated.  Numerous  studies  over  many 
decades  have  addressed  various  aspects  of  the  problems  plaguing  these  efforts  with  many 
recommendations.  Unfortunately,  most  of  these  recommendations  have  been  ignored  or  poorly 
implemented  with  limited  success.  This  work  embodies  an  exploratory  systems  approach  to  characterize 
the  system  of  acquiring  large,  complex,  socio-technological  systems  for  the  Department  of  Defense. 
Through  a  series  of  qualitative  studies  and  in-depth  interviews  with  individuals  working  in  the  Joint 
Capabilities  Integration  Development  System  (JCIDS),  the  Planning,  Programming,  Budgeting,  and 
Execution  (PPBE)  process,  and  the  Acquisition  system,  a  model  of  the  larger  ?enterprise  of  acquisition?  or 
Acquisition  System  was  developed.  The  model  has  a  scope  ranging  from  the  very  early  beginnings  of  any 
program  through  the  conclusion  of  developmental  activities.  The  methodology  used  consisted  of  stringing 
together  the  individual  pieces  of  the  system  defined  by  probabilistic  distributions  of  time  and 
corresponding  probabilistic  decision  points  into  a  model  ideal  for  discrete-event  simulation.  An  extensive 
program  of  verification  and  validation  of  the  model  was  carried  out  to  increase  confidence  in  the  model 
and  its  simulation  outcomes.  Experimental  system  interventions,  designed  to  mimic  potential  policy 
interventions  and/or  system  changes,  were  introduced  into  the  model  and  the  corresponding  outcomes 
analyzed.  Results  show  several  interventions  have  varying  degrees  of  influence  and  suggest  no  single 
antidote  exists  for  solving  the  problems  related  to  Acquisition.  Furthermore,  many  of  the  outcomes  of  the 
system  can  be  described  as  emergent  behaviors  versus  problems  stemming  from  poor  program 
management,  program  risk  management,  or  requirements  management. 


15.  SUBJECT  TERMS 


16.  SECURITY  CLASSIFICATION  OF: 

17.  LIMITATION  OF 

18.  NUMBER 

1 9a.  NAME  OF 

ABSTRACT 

OF  PAGES 

RESPONSIBLE  PERSON 

a.  REPORT 

unclassified 

b.  ABSTRACT 

unclassified 

c.  THIS  PAGE 

unclassified 

Same  as 
Report  (SAR) 

906 

Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


Disclaimer 


The  views  expressed  in  this  work  are  those  of  the  author  and  do  not  reflect  the  official  policy  or 
position  of  the  United  States  Air  Force,  Department  of  Defense,  or  the  U.S.  Government. 


2 


Identifying  Enterprise  Leverage  Points  in  Defense  Acquisition  Program 

Performance 

by 

Joseph  Robert  Wirthlin 


Submitted  to  the  Engineering  Systems  Division 
on  September  05,  2009  in  Partial  Fulfillment  of  the 
Requirements  for  the  Degree  of  Doctor  of  Philosophy  in 
Engineering  Systems 


ABSTRACT 

Large,  complex  systems  development  programs  in  the  Department  of  Defense  are  finding  it 
more  difficult  to  deliver  desired  capabilities  to  the  end  user  on  time  and  on  budget  than  ever 
before.  Evidence  exists  that  almost  all  developmental  programs  on  record  are  over  cost  and 
schedule,  costing  the  Department  and  ultimately  the  U.S.  taxpayer  billions  of  dollars  more  than 
anticipated.  Numerous  studies  over  many  decades  have  addressed  various  aspects  of  the 
problems  plaguing  these  efforts  with  many  recommendations.  Unfortunately,  most  of  these 
recommendations  have  been  ignored  or  poorly  implemented  with  limited  success. 

This  work  embodies  an  exploratory  systems  approach  to  characterize  the  system  of  acquiring 
large,  complex,  socio-technological  systems  for  the  Department  of  Defense.  Through  a  series  of 
qualitative  studies  and  in-depth  interviews  with  individuals  working  in  the  Joint  Capabilities 
Integration  Development  System  (JCIDS),  the  Planning,  Programming,  Budgeting,  and  Execution 
(PPBE)  process,  and  the  Acquisition  system,  a  model  of  the  larger  "enterprise  of  acquisition"  or 
Acquisition  System  was  developed.  The  model  has  a  scope  ranging  from  the  very  early 
beginnings  of  any  program  through  the  conclusion  of  developmental  activities.  The 
methodology  used  consisted  of  stringing  together  the  individual  pieces  of  the  system  defined 
by  probabilistic  distributions  of  time  and  corresponding  probabilistic  decision  points  into  a 
model  ideal  for  discrete-event  simulation.  An  extensive  program  of  verification  and  validation 
of  the  model  was  carried  out  to  increase  confidence  in  the  model  and  its  simulation  outcomes. 
Experimental  system  interventions,  designed  to  mimic  potential  policy  interventions  and/or 
system  changes,  were  introduced  into  the  model  and  the  corresponding  outcomes  analyzed. 
Results  show  several  interventions  have  varying  degrees  of  influence  and  suggest  no  single 
antidote  exists  for  solving  the  problems  related  to  Acquisition.  Furthermore,  many  of  the 
outcomes  of  the  system  can  be  described  as  emergent  behaviors  versus  problems  stemming 
from  poor  program  management,  program  risk  management,  or  requirements  management. 

Thesis  Supervisor:  Warren  P.  Seering 

Title:  Weber-Shaughness  Professor  of  Mechanical  Engineering  and  Engineering  Systems 


3 


[blank] 


4 


Biographical  Summary  of  Author 


Robb  Wirthlin  is  a  Lieutenant  Colonel  in  the  United  States  Air  Force.  He  graduated  from  the 
United  States  Air  Force  Academy  in  1994  with  a  degree  in  Engineering  Sciences  and  a  Foreign 
Language  Minor.  He  has  served  in  various  acquisition  and  systems  engineering  roles  within  the 
Air  Force  ranging  from  assignments  at  an  Air  Logistics  Center,  a  Development  Center,  and  at  an 
operational  facility.  He  was  awarded  a  masters  degree  in  Engineering  and  Management  from 
the  Massachusetts  Institute  of  Technology  in  2000.  He  loves  his  wife  and  children  very  much. 


5 


[blank] 


6 


Acknowledgements 

I  am  profoundly  grateful  for  the  support,  encouragement  and  guidance  of  my 
committee.  Dr.  Warren  Seering,  Dr.  Sheila  Widnall,  and  Dr.  Don  Lessard.  I  can  not  express 
enough  of  my  thanks  for  their  insight  and  wisdom,  especially  as  they  helped  me  to  see  things 
that  were  not  always  clear  to  me  and  prodded  me  in  areas  where  I  needed  encouragement. 

For  Warren,  in  particular,  I  want  to  thank  you  for  the  countless  hours  spent  teaching, 
guiding,  and  talking  with  me.  Your  enthusiasm  and  positive  attitude  carried  me  along  when  I 
felt  especially  discouraged.  Without  your  confidence  and  resolve,  I  would  not  have  finished  this 
dissertation. 

I  want  to  express  my  heartfelt  thanks  to  Dr.  Eric  Rebentisch.  As  my  perennial  sounding 
board  and  a  good  friend,  I  am  forever  grateful  for  your  timeless  hours  of  advice  and  assistance. 

I  never  could  have  imagined  the  twists  and  turns  this  effort  has  taken  and  I'm  grateful  for  the 
breakthroughs  you  handed  to  me  in  my  most  frustrating  moments. 

I  owe  the  clarity  of  this  dissertation  to  Claire  Betar,  PhD,  a  dear  friend  and  mentor. 
Without  your  patient,  kind  critiques  of  my  writing  style  and  voice,  this  work  would  fall  short  in 
many  areas.  I'm  grateful  you've  helped  me  to  clearly  communicate  and  express  the  concepts  in 
my  dissertation.  I've  learned  to  love  the  power  of  the  written  word,  the  beauty  of  the  English 
language,  and  the  importance  of  proper  grammar.  I  regret  that  I've  never  had  the  privilege  of 
being  a  student  in  one  of  your  classrooms. 

I  also  want  to  thank  Capt  Paul  Conner  for  the  hours  of  dedicated  research  done  for  me, 
especially  after  just  finishing  your  own  challenging  degree  program.  You  did  some  real  grunt 
work  that  I  didn't  have  the  time  or  patience  to  do.  Without  your  help,  I  am  sure  I  would  still  be 
wallowing  in  the  midst  of  multiple  databases  trying  to  sort  out  data. 

To  the  professionals  working  in  the  DOD  Acquisition  system,  I  thank  you  for  your 
dedicated  service,  candid  insights,  feedback,  and  information.  This  dissertation  would  not  have 
been  possible  without  your  efforts.  I  hope  this  work  will  someday  make  your  work  better. 

To  my  friends  and  colleagues  at  MIT  in  the  Engineering  Systems  Division  and  especially 
the  Lean  Advancement  Initiative:  Thank  You!  I  will  miss  the  daily  interaction,  the  helpful 
feedback,  and  the  stimulating  discussions.  To  those  of  you  in  the  Silo  -  Dan,  Dave,  Joao,  Sid, 
Pedzi,  Dan,  Claudia,  Sebastian,  and  Damien  -  I  can  not  thank  you  enough.  We  worked,  laughed, 
and  played  hard  together.  I  look  forward  to  strengthening  our  friendships  and  collaborating 
professionally  in  the  future. 

I  would  like  to  thank  my  parents  for  helping  me  learn  to  work,  encouraging  me  to  reach 
for  the  stars,  and  teaching  me  to  trust  in  God.  I  am  grateful  for  their  examples  and  love. 

My  wife  and  children  have  supported  me  and  encouraged  me,  made  me  laugh  and 
motivated  me  to  do  my  best.  I  want  to  thank  them  and  especially  thank  my  wife  for 
encouraging  me  to  go  to  MIT  and  believe  in  myself  that  I  could  go  back  again  to  MIT  and  earn  a 
doctorate.  I  am  grateful  for  the  heavy  load  she  carried  that  enabled  me  focus  on  the  work 
needed  to  complete  this  degree. 

I  believe  God  is  the  source  of  all  knowledge  and  He  has  inspired  me  and  blessed  me  to 
complete  this  challenging  degree.  I  have  learned  a  lot  and  I  am  looking  forward  to  learning 
even  more.  Furthermore,  our  family  has  learned  from,  grown,  and  overcome  great  obstacles 
with  the  support,  blessings  and  divine  intervention  of  Our  Heavenly  Father,  for  which  I  will 
always  be  thankful  and  grateful. 


7 


[blank] 


8 


Table  of  Contents 


List  of  Figures . 12 

List  of  Tables . 15 

List  of  Acronyms . 17 

CHAPTER  1  -  INTRODUCTION . 23 

Research  questions,  approach,  and  methods . 25 

Research  Limitations . 25 

Dissertation  Outline . 26 

CHAPTER  2  -  LITERATURE  REVIEW . 28 

Product  development  processes . 29 

Risk . 30 

Portfolio  Management  strategies . 33 

Enterprise  Risk  and  Portfolio  Execution . 37 

Enterprise  Acquisition  System . 38 

JCIDS . 41 

PPBE . 49 

Acquisition . 59 

Contractors . 64 

Modeling  and  Analysis . 66 

Summary  of  Literature  Review  -  Key  Take-aways . 69 

CHAPTER  3  -  ACQUISITION . 70 

Initial  Observations  and  Analysis . 72 

Data  Coding  and  Analysis . 75 

Further  Discussion . 76 

Potential  measures  for  further  research . 80 

Conclusions . 81 

CHAPTER  4  -  THE  OTHER  PARTS  OF  THE  ACQUISITION  SYSTEM . 83 

Results  and  Analysis . 85 

The  Program  Element  Monitor . 85 

Other  Identified  Issues . 88 

Other  issues . 98 

Chapter  Conclusion:  Implications  of  this  study . 102 

CHAPTER  5  -  A  MODEL  OF  THE  ENTERPRISE  ACQUISITION  SYSTEM . 104 

Model  design  and  depiction . 106 

Model  Scope . 108 

Model  Symbology . 110 

Model  Assumptions . 115 

Conclusions . 116 


9 


CHAPTER  6  -  VERIFICATION  AND  VALIDATION . 118 

Verification  of  free  style  model . 118 

Hand  Modeling . 119 

PPBE  modeling . 120 

Validation  of  free  style  model . 121 

Verification  of  computer  simulation  model . 124 

Validation  of  computer  model . 125 

AC  AT  I  Programs . 128 

ACAT  II/III  Programs . 128 

Actual  Data  Results . 129 

Comparison  of  model  outcomes  and  actual  data  -  Final  Validation . 137 

All  ACAT  results  vs  all  actual  data . 138 

ACAT  I  model  results  vs  ACAT  I  actual  results . 140 

ACAT  II  model  results  vs  ACAT  II  actual  results . 142 

ACAT  III  model  results  vs  ACAT  III  actual  data  results . 144 

Conclusions . 146 

CHAPTER  7-  MODEL  RESULTS  AND  REPRESENTATIVE  OUTPUT . 148 

Model  Parameters . 148 

Model  Simulation . 149 

Typical  model  output . 150 

Other  analyses  done;  preliminary  results . 154 

Program  End  Points . 154 

DSM  representation  and  preliminary  analysis . 159 

Model  Sensitivities . 166 

Additional  Questions  using  Sensitivity  Test  Data . 168 

Other  Questions . 169 

Further  Model  Results  and  Analysis . 170 

Conclusions . 174 

CHAPTER  8  -  HYPOTHESIS  TESTING  AND  ANALYSIS . 176 

Hypothesis . 177 

Key  Questions . 178 

Experimental  Interventions . 178 

Requirements  Swim  Lane  Interventions . 179 

Planning,  Programming,  Budgeting,  Execution  System  Swim  Lane  Interventions . 182 

Acquisition  Swim  Lane  Interventions . 183 

Other  combinations . 191 

Greatest  Impact  Interventions . 196 

Final  Analysis  and  Conclusions . 198 

CHAPTER  9  -  CONCLUSIONS  AND  SUMMARY . 203 

Qualitative  Observations . 203 

Quantitative  Findings . 208 

Overarching  Conclusions . 210 

Policy  Implications  and  Potential  System  Improvements . 212 


10 


Future  work . 214 

Recommendations . 216 

Summary . 216 

Bibliography . 218 

Appendix  A  -  Other  Studies  and  Recommendations  to  Improve  Acquisition  Outcomes..  226 

Key  Takeaways . 226 

Discussion  of  Individual  Studies . 227 

Summary  and  Conclusions . 239 

Appendix  B  -  Sample  Questions  used  in  Acquisition  Study . 240 

Appendix  C  -  Sample  questions  used  for  second  study . 242 

Appendix  D  -  Description  of  Model  and  Data  Documentation . 244 

Introductory  description  and  explanation . 244 

Project  Attributes . 246 

ACAT  Discussion . 248 

The  Programming,  Planning,  Budgeting  and  Execution  Process . 249 

Detailed  Model  Explanation . 261 

The  Pre-Milestone  A  Swim  Lanes . 263 

The  Pre-Milestone  B  Swim  Lanes . 299 

The  Pre-Milestone  C  Swim  Lanes . 332 

Summary . 372 

Appendix  E  -  Model  Documentation . 373 

SIMAN  Code . 373 

SIMAN  Global  Code . 536 

Enterprise  Acquisition  Process  Model . 584 

Submodel  for  Module  Acquisition  Planning  Activities  PreB . 654 

Submodel  for  Module  Acquisition  Planning  Activities  PreC . 656 

Submodel  for  Module  Developmental  Test  and  Evaluation . 700 

Submodel  for  Module  Early  Operational  Assessment . 708 

Submodel  for  Module  Independent  document  preA . 726 

Submodel  for  Module  Independent  document  preB . 733 

Submodel  for  Module  Independent  document  preC . 740 

Submodel  for  Module  Joint  Integration  PreA . 749 

Submodel  for  Module  Joint  Integration  PreB . 761 

Submodel  for  Module  Joint  Integration  PreC . 772 

Submodel  for  Module  Joint  Interest  preA . 784 

Submodel  for  Module  Joint  Interest  preB . 797 

Submodel  for  Module  Joint  Interest  preC . 810 

Submodel  for  Module  Set  ACAT  level . 875 

Submodel  for  Module  Study  for  ICD  Development . 884 


11 


List  of  Figures 

Figure  1 :  An  example  of  a  notional  product  development  process . 29 

Figure  2:  The  Total  Acquisition  System . 40 

Figure  3:  From  Chapter  1.3  of  the  Defense  Acquisition  Guidebook . 41 

Figure  4:  Relationship  of  Strategic  Processes  with  JCIDS . 43 

Figure  5:  Connections  between  JCIDS  and  Acquisition . 45 

Figure  6:  PPBE  Timeline . 50 

Figure  7:  "On-year"  PPBE  schedule . 51 

Figure  8:  "Off-year"  PPBE  Schedule . 51 

Figure  9:  The  US  Air  Force  Corporate  Process . 53 

Figure  10:  One  MAJCOM’s  corporate  structure . 53 

Figure  1 1 :  Figure  from  a  USAF  MAJCOM . 54 

Figure  12:  Concurrent  Program  and  Budget  Review  Process . 55 

Figure  13:  PPBE  Timing . 59 

Figure  14:  An  Overview  of  the  Acquisition  System . 60 

Figure  15:  Overlay  of  Acquisition  and  Requirements  processes . 61 

Figure  16:  Ways  to  Study  a  System . 66 

Figure  17:  A  Model  Taxonomy . 67 

Figure  18:  Portfolio  Manager  Capability  Matrix . 77 

Figure  19:  Portfolio  Domain  Space . 79 

Figure  20:  A  Holistic  View  of  the  Acquisition  System . 105 

Figure  21:  The  “Wall  Chart”  of  the  Defense  Acquisition  System  (December  2008  version)....  108 

Figure  22:  Model  Scope  in  Relation  to  the  Overall  Acquisition  System . 109 

Figure  23:  Conceptual  model  of  the  Acquisition  Enterprise . 110 

Figure  24:  Close-up  of  the  Requirements  portion  of  the  Pre-MS  A  swim  lane . Ill 

Figure  25:  Close-up  view  of  three  elements  of  Pre-MS  A  Requirements  swim  lane . 1 12 

Figure  26:  Final  Model  Representation . 1 14 

Figure  27:  Example  of  Scanned  image  of  model  feedback  form . 122 

Figure  28:  Image  of  marked-up  paper  model . 123 

Figure  29:  Data  Sources  for  Model  Validation . 126 

Figure  30:  Example  Contract  Performance  Tables  as  found  on  Page  2  of  each  MAR . 135 

Figure  3 1 :  Unequal  sample-t  test . 138 

Figure  32:  Histogram  of  time  elapsed  for  all  ACAT  programs  between  MS  B  and  MS  C . 139 

Figure  33:  Histogram  of  actual  program  data  time  elapsed  between  MS  B  and  MS  C . 139 

Figure  34:  Histogram  of  time  elapsed  for  ACAT  I  data  between  MS  B  and  MS  C . 141 

Figure  35:  Histogram  of  time  elapsed  for  ACAT  I  data  between  MS  B  and  MS  C . 141 

Figure  36:  ACAT  II  model  data  between  MS  B  and  MS  C . 143 

Figure  37:  ACAT  II  actual  time  elapsed  data  between  MS  B  and  MS  C . 143 

Figure  38:  ACAT  III  model  histogram  of  time  elapsed  between  MS  B  and  MS  C . 145 

Figure  39:  Histogram  of  ACAT  III  actual  time  elapsed  between  MS  B  and  MS  C . 145 

Figure  40:  Representative  and  partial  output  of  simulation  file . 151 

Figure  41 :  Histogram  of  model  output  at  Milestone  C . 151 

Figure  42:  Histogram  of  MS  C  arrivals  after  100000  iterations . 152 

Figure  43:  Partitioned  DSM  of  Acquisition  System . 159 

Figure  45:  Pre-MS  A  Partitioned  DSM . 161 

Figure  47:  Pre-MS  B  Partitioned  DSM . 163 


12 


Figure  49:  Pre-MS  C  Partitioned  DSM . 165 

Figure  50:  Comparison  of  MS  C  arrivals  between  forced  fonnal  system  and  any  shortcuts . 170 

Figure  51:  Graphical  depiction  of  model  outcomes . 173 

Figure  52:  Depiction  of  categories  why  schedules  slip  across  development  efforts . 231 

Figure  53:  Graphical  representation  of  PPBE  Swim  Lane . 250 

Figure  54:  First  third  of  PPBE  model . 251 

Figure  55:  Middle  third  of  PPBE  model . 253 

Figure  56:  Last  third  of  PPBE  model . 257 

Figure  57:  Final  Model  Representation . 262 

Figure  58:  Final  model  with  descriptive  labels . 263 

Figure  59:  Pre-MS  A  portion  of  model  with  close  up  sections  marked . 264 

Figure  60:  Early  Pre-MS  A  close  up . 264 

Figure  61 :  Early  Pre-MS  A  close  up  in  requirements  swim  lane  after  initial  screening . 270 

Figure  62:  Close  up  of  another  portion  of  the  early  Pre-MS  A  requirement  swim  lane . 272 

Figure  63:  Pre-MS  A  early  PPBE  activity . 274 

Figure  64:  Pre-MS  A  close  up  of  JCIDS  process  for  ICD  Development . 275 

Figure  65:  Pre  MS-A  Independent  document  process . 276 

Figure  66:  Pre-MS  A  Joint  Integration  document  process,  part  1 . 279 

Figure  67:  Pre-MS  A  Joint  Integration  document  process,  part  II . 281 

Figure  68:  Pre-MS  A  Joint  Interest  document  process,  part  1 . 282 

Figure  69:  Pre-MS  A  Joint  Interest  document  process,  part  II . 284 

Figure  70:  Pre-MS  A  PPBE  and  early  Acquisition  activities . 286 

Figure  71:  Pre-MS  A  AOA  activities . 289 

Figure  72:  Pre-MS  A  Acquisition  activities  parallel  to  AOA . 291 

Figure  73:  Pre-MS  A  COA  approval  processes . 293 

Figure  74:  Pre-MS  A  Acquisition  swim  lane  after  COA  selection . 294 

Figure  75:  Pre-MS  A  final  funding  check  prior  to  MS  A  approval . 295 

Figure  76:  Pre-MS  A  Milestone  Decision  activity . 297 

Figure  77:  Pre -MS  B  Swim  Lanes  with  Reference  Figures . 299 

Figure  78:  Pre -MS  B  Early  Requirements  Swim  Lane . 300 

Figure  79:  Pre -MS  B  Entry  into  fonnal  requirements  process  at  MAJCOM . 302 

Figure  80:  Pre -MS  B  Requirements  swim  lane  MAJCOM  process . 303 

Figure  81:  Pre -MS  B  Requirements  swim  lane  JCIDS  process . 304 

Figure  82:  Pre-MS  B  Requirements  Independent  Document  process . 305 

Figure  83:  Pre-MS  B  Requirements  swim  lane  Joint  Integration  process,  Part  I . 307 

Figure  84:  Pre-MS  B  Requirements  swim  lane  Joint  Integration  process,  Part  II . 309 

Figure  85:  Pre-MS  B  Requirements  swim  lane  Joint  Interest  process,  Part  1 . 311 

Figure  86:  Pre-MS  B  Requirements  swim  lane  Joint  Interest  process,  part  II . 313 

Figure  87:  Pre-MS  B  early  acquisition  swim  lane  activities . 315 

Figure  88:  Pre-MS  B  Acquisition  costing  and  acquisition  planning . 317 

Figure  89:  Pre-MS  B  Contract  start-up  activities . 318 

Figure  90:  Pre-MS  B  Acquisition  swim  lane  Systems  Engineering  activities . 318 

Figure  91 :  Pre-MS  B  Acquisition  swim  lane  preparations  for  Acquisition  Panels . 320 

Figure  92:  Pre-MS  B  PPBE  Funding  check . 322 

Figure  93:  Pre-MS  B  Acquisition  swim  lane  Milestone  B  decision . 324 

Figure  94:  Pre -MS  B  Acquisition  swim  lane  financial  uncertainty  engine . 325 


13 


Figure  95:  Pre-MS  B  Contractor  swim  lane  uncertainty  generator  and  contract  engine . 327 

Figure  96:  Pre-MS  B  Acquisition  swim  lane  program  management  and  oversight  loop . 329 

Figure  97:  Pre-MS  C  Swim  Lanes  with  Reference  Figures . 332 

Figure  98:  Pre-MS  C  Early  Requirements  Swim  Lane . 333 

Figure  99:  Pre-MS  C  Entry  into  formal  requirements  process  at  MAJCOM . 335 

Figure  100:  Pre-MS  C  Requirements  swim  lane  MAJCOM  process . 336 

Figure  101:  Pre-MS  C  Requirements  swim  lane  JCIDS  process . 337 

Figure  102:  Pre-MS  C  Requirements  Independent  Document  process . 338 

Figure  103:  Pre-MS  C  Requirements  swim  lane  Joint  Integration  process,  Part  I . 340 

Figure  104:  Pre-MS  C  Requirements  swim  lane  Joint  Integration  process,  Part  II . 342 

Figure  105:  Pre-MS  C  Requirements  swim  lane  Joint  Interest  process,  Part  1 . 344 

Figure  106:  Pre-MS  C  Requirements  swim  lane  Joint  Interest  process,  part  II . 347 

Figure  107:  Pre-MS  C  PPBE  Early  funding  check . 349 

Figure  108:  Pre-MS  C  early  acquisition  swim  lane  activities . 350 

Figure  109:  Pre-MS  C  Acquisition  costing  and  acquisition  planning . 35 1 

Figure  110:  Pre-MS  C  Contract  start-up  activities . 352 

Figure  111:  Pre-MS  C  Early  Systems  Engineering  Preliminary  Design  Review  activity . 353 

Figure  1 12:  Pre-MS  C  Acquisition  swim  lane  Critical  Design  Reviews . 354 

Figure  113:  Pre-MS  C  Acquisition  swim  lane  fabrication,  assembly  and  testing . 356 

Figure  1 14:  Pre-MS  C  Acquisition  swim  lane  System  Verification  Review . 359 

Figure  115:  Pre-MS  C  Acquisition  swim  lane  preparations  for  Acquisition  Panels . 360 

Figure  116:  Pre-MS  C  PPBE  Funding  check . 362 

Figure  117:  Pre-MS  C  Acquisition  swim  lane  Milestone  B  decision . 363 

Figure  118:  Pre-MS  C  Acquisition  swim  lane  financial  uncertainty  engine . 365 

Figure  119:  Pre-MS  C  Contractor  swim  lane  uncertainty  generator  and  contract  engine . 367 

Figure  120:  Pre-MS  C  Acquisition  swim  lane  program  management  and  oversight  loop . 369 


14 


List  of  Tables 

Table  1:  Table  of  Validation  and  Approval  Authority . 46 

Table  2:  Modification  Thresholds  (Financial  Thresholds) . 47 

Table  3:  Document  Certification/Validation  Authority . 48 

Table  4:  Issues  specific  for  Program  Element  Monitors  (PEMs) . 86 

Table  5:  Common  issues  identified  by  individuals  in  JCIDS  and  PPBE . 89 

Table  6:  Common  issues  identified  by  individuals  in  JCIDS  and  the  user  community . 92 

Table  7:  Issues  identified  by  individuals  within  JCIDS  only . 93 

Table  8:  Issues  identified  by  individuals  within  PPBE  only . 95 

Table  9:  Example  table  of  hand  modeling  trials . 1 19 

Table  10:  Explicit  PPBE  hand-modeling . 120 

Table  1 1 :  Multi-source  Acquisition  Program  Schedule  Data . 132 

Table  12:  Multi-source  Acquisition  Program  Cost  Data . 133 

Table  13:  t-Test:  Two-Sample  test  assuming  unequal  variances  between  data  for  all  ACATs..  140 

Table  14:  AC  AT  I  model  and  actual  data  test  results . 142 

Table  15:  AC  AT  II  model  and  actual  t-test  results . 144 

Table  16:  t-test  results  for  ACAT  III  data . 146 

Table  17:  Basis  statistics  for  Milestone  C  model  output . 153 

Table  18:  Basic  statistics  for  MS  C  model  output  with  additional  iterations . 154 

Table  19:  Analysis  of  model  tenninating  points . 155 

Table  20:  Analysis  of  model  tenninating  points  excluding  early  rejections . 156 

Table  21 :  Analysis  of  model  tenninating  points  excluding  early  rejected  &  diverted  programs  157 

Table  22:  End  point  summary  statistics  for  sample  of  48500 .  158 

Table  23:  End  point  summary  statistics  for  sample  of  100,000 .  158 

Table  24:  Original  Model  data  outcomes  at  MS  C . 167 

Table  25:  Changed  model  outcomes  at  MS  C . 168 

Table  26:  Original  model  outcomes  at  MS  C  with  no  excursions  allowed . 168 

Table  27:  Air  staff  intervention  model  outcomes  at  MS  C  with  no  excursions  allowed . 168 

Table  28:  Additional  Data  Analysis . 172 

Table  29:  Requirements  swim  lane  analysis . 173 

Table  30:  Air  Staff  intervention  results . 180 

Table  31:  MAJCOM  approval  bodies  result . 181 

Table  32:  Critical  comments  results . 182 

Table  33:  Funding  Stability  Results . 183 

Table  34:  Acquisition  Kill  results . 184 

Table  35:  Approval  bodies  results . 185 

Table  36:  Technical  Interventions  Results . 186 

Table  37:  PDR  intervention  results . 187 

Table  38:  CDR  Intervention . 188 

Table  39:  DRR  Intervention . 188 

Table  40:  TRR  Intervention  Results . 189 

Table  41 :  Test  trades  intervention  results . 190 

Table  42:  SVR  Intervention . 191 

Table  43:  Systems  Enginering  Interventions . 192 

Table  44:  SE  and  Acquisition  Kill  Intervention  Results . 193 

Table  45:  MAJCOM  and  Acquisition  approval  bodies  intervention  results . 194 


15 


Table  46:  Funding  and  Technical  Uncertainty  Intervention  Results . 195 

Table  47:  Random  Eight  Intervention  results . 196 

Table  48:  Top  Three  Interventions  Results . 197 

Table  49:  All  Interventions  combined  results . 198 

Table  50:  Most  and  Least  Significant  Categories  of  Reasons  for  Schedule  Problems . 231 

Table  5 1 :  Description  and  Decision  Authority  for  ACAT  I  -  III  Programs . 249 

Table  52:  Approval  Authority  level  for  JCIDS  documents  based  on  ACAT  level . 276 


16 


List  of  Acronyms 

A1 

Manpower  and  Personnel 

A2 

Intelligence 

A3 

Air,  Space  and  Information  Operations 

A4 

Logistics 

A5 

Plans  and  Requirements 

A6 

Communications 

A7 

Installations  and  Mission  Support 

A8 

Strategic  Plans  and  Programs 

A9 

Analyses,  Assessments  and  Lessons  Learned 

ACAT 

Acquisition  Category 

ACC 

Air  Combat  Command 

ACWP 

Actual  Cost  of  Work  Performed 

ADM 

Acquisition  Decision  Memorandum 

AF 

Air  Force 

AFAKSS 

Air  Force  Acquisition  Knowledge  Sharing  System 

AFAM 

Air  Force  Acquisition  Model 

AFB 

Air  Force  Board 

AFB 

Air  Force  Base 

AFC 

Air  Force  Council 

AFDO 

Award  Fee  Designating  Official 

AFG 

Air  Force  Group 

AFI 

Air  Force  Instruction 

AFIT 

Air  Force  Institution  of  Technology 

AFMC 

Air  Force  Materiel  Command 

AFRL 

Air  Force  Research  Laboratory 

AFROCC 

Air  Force  Requirements  for  Operational  Capabilities  Council 

AIS 

Automated  Information  System 

ALC 

Air  Logistics  Center 

AOA 

Analysis  of  Alternatives 

APB 

Acquisition  Program  Baseline 

APOM 

Amended  Program  Objective  Memorandum 

AQ 

refers  to  SAF/AQ 

AQX 

refers  to  SAF/AQX 

ASC 

Aeronautical  Systems  Center 

ASD 

Assistant  Secretary  of  Defense 

AT&L 

Acquisition,  Technology  and  Logistics 

BAC 

Budget  at  Completion 

BCG 

Boston  Consulting  Group 

BCP 

Budget  Change  Proposal 

BCWP 

Budgeted  Cost  for  Work  Performed 

BCWS 

Budgeted  Cost  for  Work  Scheduled 

BES 

Budget  Estimate  Submission 

BPM 

Business  Process  Modeling 

BR 

Budget  Request 

17 


C3I 

C4CS 

C&l 

CAE 

CBA 

CDD 

CDR 

CJCSI 

CJCSM 

CIO 

C-level 

COA 

COCOMS 

COMACC 

CONOPS 

CP 

CP 

CPD 

CPI 

CPIF 

CPR 

CRS 

CSAF 

CS&P 

CSP 

CV 

CV 


Command,  Control,  Communications,  and  Intelligence 

Command,  Control,  Communications,  and  Computer  Systems 

Communication  and  Information 

Component  Acquisition  Executive 

Capabilities  Based  Assessment 

Capability  Development  Document 

Critical  Design  Review 

Chairman  of  the  Joint  Chiefs  of  Staff  Instruction 

Chairman  of  the  Joint  Chiefs  of  Staff  Manual 

Chief  Information  Officer 

Corporate  level 

Course  of  Action 

Combatant  Commands 

Commander  ACC 

Concept  of  Operation 

Capability  Plan 

Change  Proposal 

Capability  Production  Document 

Cost  Efficiency 

Cost  Plus  Incentive  Fee 

Cost  Performance  Report 

Congressional  Research  Service 

Chief  of  Staff  of  the  Air  Force 

Competitive  Sourcing  and  Privatization 

Cost,  Schedule,  and  Performance 

Vice  Chairman 

Cost  Variance 


D  Disconnect 

DAB  Defense  Acquisition  Board 

DAES  Defense  Acquisition  Executive  System 

DAMIR  Defense  Acquisition  Management  Information  Retrieval 

DAPA  Defense  Acquisition  Performance  Assessment 

DAU  Defense  Acquisition  University 

DAWIA  Defense  Acquisition  Workers  Improvement  Act 

DOD  Department  of  Defense 

DODI  Department  of  Defense  Instruction 

DOTMLPF  Doctrine,  Organization,  Training,  Material,  Leadership  and  Education,  Personnel  and 
Facilities 

DCR  DOTMLPF  Change  Recommendation 

DIA  Defense  Intelligence  Agency 

DRR  Design  Readiness  Review 

DSM  Design  Structure  Matrix 

DT&E  Developmental  Test  and  Evaluation 

DTIC  Defense  Technical  Information  Center 


EAC  Estimate  at  Completion 


18 


ECP 

Engineering  Change  Proposal 

EOA 

Early  Operational  Assessment 

EPP 

Enhanced  Planning  Process 

ESC 

Electronic  Systems  Center 

EVMS 

Earned  Value  Management  Systems 

FCB 

Functional  Capabilities  Board 

FIFO 

First  In,  First  Out 

FMECA 

Failure  Mode,  Effects,  and  Criticality  Analysis 

FOC 

Full  Operational  Capability 

FRP 

Full  Rate  Production 

FSA 

Functional  Solutions  Analysis 

FY 

Fiscal  Year 

FYDP 

Future  Years  Defense  Program/Plan 

GAO 

Government  Accountability  Office 

CGIC 

Global  Cyberspace  Integration  Center 

GE 

General  Electric 

HPT 

High  Performance  Team 

HQ 

Headquarters 

1 

Initiative 

ICAF 

Industrial  College  of  the  Armed  Forces 

ICD 

Initial  Capabilities  Document 

ICE 

Independent  Cost  Estimate 

IDA 

Institute  for  Defense  Analysis 

IOC 

Initial  Operating  Capability 

IOT&E 

Initial  Operational  Test  &  Evaluation 

IPL 

Integrated  Priority  List 

IPT 

Integrated  Process  Team 

IRSS 

Integrated  Requirement  Support  System 

ISP 

Integrated  Support  Plan 

IT 

Information  Technology 

ITAB 

Information  Technology  Acquisition  Board 

ITT 

Integrated  Test  Team 

J1 

Manpower  and  Personnel 

J2 

Joint  Staff  Intelligence 

J3 

Operations 

J4 

Logistics 

J5 

Strategic  Plans  and  Policy 

J6 

Command,  Control,  Communications,  and  Computer  Systems 

J7 

Operational  Plans  &  Joint  Force  Development 

J8 

Force  Structure  Resources  and  Assessment 

JCB 

Joint  Capabilities  Board 

JCD 

Joint  Capability  Document 

JCIDS 

Joint  Capabilities  Integration  Development  System 

19 


JFCOM 

Joint  Forces  Command 

JIC 

Joint  Integrating  Concepts 

JPD 

Joint  Potential  Designator 

JPG 

Joint  Programming  Guidance 

JROC 

Joint  Requirements  Oversight  Council 

JS 

Joint  Staff 

KPP 

Key  Performance  Parameter 

KSA 

Key  System  Attribute 

LCMP 

Life  Cycle  Management  Plan 

LRIP 

Limited  Rate  Incremental  Production 

MAIS 

Major  Automated  Information  System 

MAJCOM 

Major  Command 

MAR 

Monthly  Acquisition  Report 

MAUT 

Multi-Attribute  Utility  Theory 

MBI 

Major  Budget  Issue 

MDA 

Milestone  Decision  Authority 

MDAP 

Major  Defense  Acquisition  Program 

MILCON 

Military  Construction 

MIT 

Massachusetts  Institute  of  Technology 

MR 

Management  Reserve 

MS 

Milestone 

NAS 

National  Academy  of  Sciences 

NIP 

National  Intelligence  Program 

NPD 

New  Product  Development 

NPS 

Naval  Postgraduate  School 

NSS 

National  Security  Strategy 

0 

Offset 

OMB 

Office  of  Management  and  Budget 

OPR 

Officer  Performance  Report 

OSD 

Office  of  the  Secretary  of  Defense 

OT&E 

Operational  Test  and  Evaluation 

P&R 

Planning  and  Requirements 

PB 

President's  Budget 

PBD 

Program  Budget  Decision 

PCP 

Program  Change  Proposals 

PD 

Product  Development 

PDM 

Program  Decision  Memorandum 

PDR 

Preliminary  Design  Review 

PE 

Program  Element 

PEM 

Program  Element  Monitor 

PEO 

Program  Executive  Officer 

PHA 

Physical  Health  Assessment 

20 


PM  Program  Manager 

POM  Program  Objective  Memorandum 

POPS  Probability  of  Program  Success 

PPBE  Planning,  Programming,  Budgeting,  and  Execution 

PPBES  Planning,  Programming,  Budgeting,  and  Execution  System  (no  longer  favored) 

PPD  Program  Planning  Document 

PR  Program  Review 

QDR  Quadrennial  Defense  Review 

RAND  Research  ANd  Development  Corporation 

R&D  Research  and  Development 

RCT  Requirements  Crosswalk  Table 

RFP  Request  for  Proposal 

RMP  Radar  Modernization  Program 

RDT&E  Research,  Development,  Test  and  Evaluation 

RSR  Requirements  Strategy  Review 

SACOM  Sustainment/Acquisition  Composite  Model 

SAE  Service  Acquisition  Executive 

SAF  Secretary  of  the  Air  Force 

SAF/AQ  Secretary  of  the  Air  Force  -  Acquisition 

SAF/AQX  Secretary  of  the  Air  Force  -  Acquisition  Integration 

SAF/FMB  Secretary  of  the  Air  Force  -  Budget 

SAF/XC  Secretary  of  the  Air  Force  -  Warfighting  Integration  &  Chief  Information  Officer 

SAR  Special  Access  Required 

SAR  Selected  Acquisition  Report 

SE  Systems  Engineering 

SES  Senior  Executive  Service 

SIMAN  SIMulation  Analysis 

SLRG  Senior  Leadership  Review  Group 

SMART  System  Metric  and  Reporting  Tool 

SPG  Strategic  Planning  Guidance 

SPI  Schedule  Efficiency 

SPO  System  Program  Office 

SPOC  Special  Access  Required  (SAR)  Programs  Oversight  Committee 

SPRG  Special  Program  Review  Group 

SSA  Source  Selection  Authority 

SV  Schedule  Variance 

SVC  Service 

SVR  System  Verification  Review 

T&E  Test  and  Evaluation 

TDS  Technology  Development  Strategy 

TEMP  Test  and  Evaluation  Master  Plan 

TRR  Test  Readiness  Review 

US  United  States 


21 


USAF 

use 

USD 

VAC 

VSM 


United  States  Air  Force 
United  States  Code 
Undersecretary  of  Defense 

Variance  at  Completion 
Value  Stream  Mapping 


22 


CHAPTER  1  -  INTRODUCTION 

Throughout  the  twentieth  century,  and  into  the  beginnings  of  the  21st,  the  United  States 
military  has  enjoyed  unprecedented  superiority  in  the  systems  and  methods  used  to  gain  victory  on  the 
battlefield.  These  tangible  results  are  the  outcome  of  thousands  of  people  working  to  design,  develop 
and  acquire  complex  weapons  systems.  However,  throughout  the  past  four  decades,  and  perhaps  even 
longer,  the  United  States  Defense  establishment  has  been  fighting  another  war;  one  that  it  appears  to 
be  losing  badly--that  of  budgets  and  schedules  out  of  control  in  the  development  of  its  systems. 
Furthermore,  the  trends  seem  to  be  getting  worse.  In  the  early  spring  of  2009,  the  Government 
Accountability  Office  (GAO)  released  scathing  reports  on  the  state  of  defense  acquisitions  [1],  Nearly  all 
of  the  complex  systems  and  development  examined  by  these  reports  were  over  budget  or  over  schedule 
or  both  [2], 

These  reports  come  on  the  heels  of  and  are  merely  an  appendix  to  the  many  reports  that  have 
been  issued  since  the  early  1960s  decrying  the  state  of  defense  acquisition  and  bemoaning  its 
outcomes.  In  one  of  the  more  recent  studies,  the  Defense  Acquisition  Performance  Assessment  (DAPA) 
examined  the  history  of  acquisition  reform  in  the  US  military  and  found  that  most  of  the  substantive 
reform  suggestions  and  recommended  policy  changes  in  those  historical  studies  were  either  ignored  or 
trivialized  [3,  4],  Although  the  DAPA  report's  own  conclusions  have  been  warmly  embraced,  their  own 
recommendations  have  met  a  similar  fate:  a  tepid  response  from  both  the  Department  of  Defense  and 
congressional  leadership  as  noted  in  the  summary  of  a  recently  published  National  Academy  of  Sciences 
report  about  the  early  phases  of  Air  Force  Acquisition  [5], 

The  structure  and  appearance  of  the  organizations  responsible  to  acquire  new  systems  have 
only  grown  more  complicated  through  the  years.  Between  policy  choices  and  statutory  requirements, 
the  Department  of  Defense  has  developed  a  number  of  processes  and  organizations  that  help  manage 
systems  acquisition.  A  virtual  army  of  largely  unsung  skilled  professionals  toil  to  deliver  these  systems 
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to  the  field.  Nevertheless,  Congressional  concern  about  the  acquisition  of  systems  is  high.  In  the  House 


Armed  Services  Committee's  report  on  the  FY  2007  defense  authorization  bill  it  states: 

Simply  put,  the  Department  of  Defense  (DOD)  acquisition  process  is  broken.  The  ability  of  the 
department  to  conduct  the  large-scale  acquisitions  required  to  ensure  our  future  national 
security  is  a  concern  of  the  committee.  The  rising  costs  and  lengthening  schedules  of  major 
defense  acquisition  programs  lead  to  more  expensive  platforms  fielded  in  fewer  numbers.  The 
committee's  concerns  extend  to  all  three  key  components  of  the  acquisition  process  including 
requirements  generation,  acquisition  and  contracting,  and  financial  management  [6]  . 

The  idea  that  all  of  the  major  system  components  are  not  functioning  properly  resonates  with 

many  of  those  working  in  the  acquisition  system.  Recently,  various  organizations  have  suggested 

product  portfolio  management  and  better  risk  management  as  the  way  to  address  the  worsening  trends 

of  defense  acquisition  [7],  The  thinking  goes  that  if  systems  are  managed  as  portfolios,  trade-offs  could 

be  made  across  that  portfolio,  both  to  manage  the  throughput  and  also  to  optimize  resource 

deployment  to  get  better  outcomes.  Risk  is  a  natural  part  of  that  discussion.  The  United  States  Air 

Force  is  currently  engaged  in  an  effort  to  adopt  these  ideas  and  is,  therefore,  quite  interested  in 

portfolio  management  and  risk. 

Some  might  argue,  though,  that  despite  the  processes,  policies  and  other  controls  that  are  in 
place,  and  based  on  historical  performance,  it  appears  that  the  Defense  Department  is  willing  to  pay  any 
price  versus  managing  to  a  cost  or  schedule.  Still  others  despair  over  the  daunting  challenges  the 
acquisition  system  faces.  For  all  of  the  reasons  outlined  above,  this  study  was  undertaken  to  better 
understand  the  performance  of  the  overall  acquisition  system,  including  its  major  processes  and 
important  stakeholders.  What  follows  has  become  an  instructive  journey  through  a  process  of  research 
that  did  not  have  as  a  foregone  conclusion  any  ideas  or  recommendations,  the  use  of  any  modeling  or 
simulation  approach,  or  any  other  kind  of  analysis  framework.  The  easy  answer  would  have  been  to 
look  merely  at  the  outcomes  of  the  acquisition  system  and  conclude  that  the  acquisition  process  is  the 
broken  link  in  the  chain,  but  rather  this  journey  took  a  deeper  and  broader  look  at  all  of  the  components 
of  acquisition.  This  approach  led  to  a  series  of  insights  and  discoveries  culminating  in  the  current  form 
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of  this  research  that  uses  discrete  event  simulation  to  verify  and  validate  the  insights  and  contributions 


documented  in  this  work. 

Research  questions,  approach,  and  methods 

The  questions  that  guided  this  research  are  neither  new  nor  profound.  Simply  stated,  the  main 
question  was,  "How  does  the  acquisition  system  work?"  A  follow-up  question  was,  "Why  does  the 
system  behave  the  way  that  it  does?"  And  finally,  "Are  there  things  that  can  be  done  to  improve  the 
system?" 

Initially,  a  great  deal  of  effort  was  spent  reading  as  much  as  possible  that  was  written  about  the 
system.  The  sources  for  this  information  included  official  documentation,  books,  and  journal  articles  or 
other  materials  written  about  the  acquisition  system.  Over  time,  this  research  effort  was  expanded  to 
include  the  other  portions  of  the  acquisition  system,  namely  the  requirements  portion  and  the  funding 
portion  of  the  system. 

After  becoming  well-versed  in  literature,  several  small  studies  were  undertaken  to  better 
understand  the  acquisition  system.  The  first  study  was  done  with  acquisition  professionals,  and  the 
second  study  looked  upon  those  learnings  and  interviewed  players  in  the  other  two  systems. 

Building  upon  all  these  efforts,  a  model  was  developed  to  capture  the  things  that  were  learned 
as  well  as  to  frame  the  problem  in  a  way  that  could  be  studied  in  depth  and  in  a  repetitive  manner  in 
order  to  gain  insight  and  understanding  about  the  behavior  of  the  system. 

Research  Limitations 

The  research  presented  here  is  not  intended  to  be  the  final  word,  nor  the  last  study  ever 
conducted  about  the  overall  acquisition  system.  The  sheer  size  and  complexity  of  the  system  required 
several  assumptions  to  be  made,  which  will  be  delineated  in  later  chapters,  in  order  to  keep  the 
problem  tractable.  Furthermore,  even  though  a  number  of  people  were  interviewed,  and  a  great  deal  of 
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effort  was  put  into  the  verification  and  validation  of  the  information  received  and  recorded,  these 
people  still  represent  a  small  sample  of  the  overall  workforce  in  the  Department  of  Defense.  These 
people  undoubtedly  carry  their  own  biases  and  understandings  of  the  system.  While  a  great  deal  of 
effort  was  made  to  ensure  that  the  responses  and  their  understanding  of  the  system  was  reasonable, 
undoubtedly  there  are  a  multitude  of  differing  opinions  throughout  the  department.  Therefore,  there  is 
a  possibility  that  certain  things  were  omitted  or  misrepresented.  Other  items  may  have  received 
disproportionate  weight  or  importance  in  this  discussion.  However,  it  is  hoped  that  the  results  of  this 
work  will  provide  a  broad  foundation  for  future  research,  and  even  greater  insights  into  the  operation 
and  behavior  of  the  Department  of  Defense's  acquisition  system. 

Dissertation  Outline 

The  following  is  a  brief  description  of  the  outline  of  this  dissertation.  Chapter  2  contains  a 
review  of  the  literature.  Following  some  initial  definitions,  discussions  about  product  development 
processes  will  take  place.  Much  of  the  space  is  devoted  to  the  topics  of  risk  and  portfolio  management 
in  a  product  development  context,  followed  by  an  overview  of  the  extended  acquisition  system, 
sometimes  called  the  enterprise  of  acquisition,  including  a  discussion  of  the  three  major  sub  processes 
of  acquisition  management,  requirements,  and  the  financial  process.  Finally,  there  will  be  a  short 
discussion  about  using  simulation  for  modeling  and  analysis  and  key  conclusions  synthesized  from  all  of 
the  literature.  Chapter  3  describes  the  results  of  the  first  in-depth  study  of  acquisition  done  as  part  of 
this  work.  It  investigates  the  use  of  portfolios  and  risk  in  system  development  and  examines  the 
acquisition  system  in  more  depth.  The  examination  reviews  many  of  the  insights  into  the  system-level 
process  gained  by  interviewing  key  players  within  the  acquisition  system.  Chapter  4  presents  the 
analysis  of  another  study  of  acquisition,  but  focusing  solely  on  the  requirements  and  financial  processes 
involved.  Together,  these  two  studies  help  lay  the  foundation  for  the  modeling  of  the  research  that  this 
dissertation  describes.  Chapter  5  describes  the  development  of  the  model  of  the  extended  acquisition 
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system,  embodying  all  of  the  insights  and  other  things  learned  in  the  earlier  stages  of  this  research.  The 


basic  structure,  approach  and  rationale  of  the  modeling  choices  will  be  given  in  this  chapter.  Chapter  6 
covers  the  steps  taken  to  verify  and  validate  the  model.  Chapter  7  explains  the  operation  of  the  model. 

It  introduces  the  initial  setup  and  operation  of  the  model,  as  well  as  providing  a  glimpse  of  the  typical 
output  from  the  model  and  a  representative  set  of  outcomes.  A  secondary  analysis  using  Design 
Structure  Matrices  is  presented,  showing  the  insights  gained  from  using  this  tool  and  perspective. 
Chapter  8  introduces  the  specific  hypothesis,  key  questions  and  interventions  that  were  implemented  by 
simulating  the  model  under  specific  conditions.  The  analysis  and  interpretation  of  the  interventions  and 
their  results  comprise  the  bulk  of  this  chapter.  Finally,  chapter  9  concludes  by  outlining  the  several 
conclusions  that  can  be  drawn  from  this  work  with  an  overall  summary  of  the  dissertation.  Included  in 
this  chapter  are  recommendations  for  future  work  as  well  as  policy  recommendations  that  will  positively 
impact  the  enterprise  of  acquisition.  Several  appendices  exist  to  give  better  understanding  of  the 
model.  Appendix  A  lists  a  representative  sampling  of  questions  used  in  the  initial  interviews  of  the 
different  acquisition  subsystems.  Appendix  B  contains  a  thorough  step-by-step  explanation  of  the 
model  details.  Appendix  C  contains  a  copy  of  the  model  source  code  in  the  SIMAN  simulation  language. 
Appendix  D  contains  an  overview  of  other  studies  about  cost  and  schedule  performance  of  the 
acquisition  system. 

Major  contributions  of  this  work  include  the  introduction  of  a  qualitative  and  quantitative 
approach  to  studying  large  complex  systems  using  discrete-event  simulation,  and,  showing  that 
Acquisition  System  outcomes  are  influenced  by  emergent  behaviors  of  the  system.  The  emergent 
behaviors  of  the  system  are  those  unexpected  consequences,  system  attributes  and  influences 
stemming  from  process  design,  interactions,  and  execution  of  the  component  processes  of  the  larger 
system  which  were  neither  designed,  neither  intended  nor  anticipated. 
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CHAPTER  2  -  LITERATURE  REVIEW 

This  chapter  contains  the  background  and  the  rationale  for  studying  this  problem  through  a 
close  examination  of  the  literature.  Since  the  process  of  developing  large  complex  systems  for  the 
defense  establishment  is  very  complicated,  various  areas  of  literature  will  be  examined  in  order  to 
thoroughly  evaluate  the  domain  space  of  the  overall  process,  broken  down  into  four  key  areas.  First, 
generic  product  development  processes  will  be  reviewed,  followed  by  a  more  focused  discussion  of  risk. 
Combined,  these  two  topics  lead  into  a  discussion  about  portfolio  management,  followed  by  reviewing 
the  literature  about  the  enterprise  of  acquisition,  consisting  of  JCIDS,  PPBE,  and  the  traditional 
acquisition  system  (comprised  of  government  personnel  and  contractors).  Next,  a  short  examination  of 
the  relevant  literature  using  modeling  and  simulation  for  these  kinds  of  activities  will  be  discussed. 
Finally,  these  will  all  be  wrapped  up  into  key  conclusions,  which  set  the  stage  for  a  thorough 
understanding  of  the  key  processes  and  issues  at  work  within  the  acquisition  system. 

A  few  definitions  are  in  order.  First,  the  United  States  Air  Force  processes  used  in  the 
development  of  large  complex  systems  will  be  considered  as  a  surrogate  for  all  the  other  branches  of 
service.  The  terms  "acquisition,  acquisition  system,  acquisition  program"  all  refer  to  their  application 
under  the  auspices  of  the  United  States  Air  Force.  Second,  the  terms  "project  and  project  management" 
are  often  interchangeably  used  with  the  terms  "program  and  program  management"  in  the  US  Air 
Force.  There  are  some  differences  between  usages  of  the  terms  because  a  project  typically  refers  to  a 
smaller  development  effort  of  a  larger  program.  A  program,  then,  might  be  the  F-16  or  the  C-17  or 
another  large  defense  system.  A  project,  on  the  other  hand,  might  be  a  sensor  that  is  going  to  be  part  of 
the  F-16  or  the  C-17  or  a  satellite  space  system.  However,  in  terms  of  high-level  discussions,  the 
meaning  is  interchangeable  although  the  word  "program"  is  the  preferred  vernacular.  The  literature 
also,  albeit  somewhat  sloppily,  regards  and  treats  both  of  these  terms  nearly  the  same,  i.e.  projects  and 
programs. 
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Product  development  processes 

Since  the  overall  purpose  of  the  Defense  Department's  acquisition  system  is  the  development  of 
a  solution  to  a  defined  material  need,  it  is  only  natural  to  first  look  at  product  development  processes  in 
general.  There  are  many  different  approaches  that  one  can  take  in  developing  a  new  product.  One  of 
the  most  common  forms  is  that  of  a  stage  gate  process,  where  new  products  are  developed  over  time 
and  slowly  make  their  way  through  a  defined  product  development  process  [8],  This  process  consists  of 
several  distinct  phases  where  short-term  goals  are  realized.  These  phases  are  called  stages.  In  order  to 
proceed  to  the  next  stage,  a  gate  or  milestone  review  must  be  successfully  accomplished.  A  gate  is  an 
opportunity  for  leadership  to  review  the  progress  of  the  development  project  and  determine  whether  or 
not  it  will  proceed.  During  this  incubation  period,  if  you  will,  certain  projects  are  expected  to  be  killed, 
while  others  that  show  promise  will  be  carried  forward  gaining  more  and  more  definition  and  fidelity 
until  they  are  delivered  [8,  9],  The  U.S.  Air  Force  has  adopted  this  approach  and  manages  with  a 
somewhat  similarly  structured  phase  gate  process  [10], 
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[8] 

Figure  1:  An  example  of  a  notional  product  development  process 

In  the  product  development  literature,  a  recent  trend  has  been  to  focus  on  some  of  the 
underlying  mechanics  required  for  product  development.  More  specifically,  focus  has  been  on  the 
decisions  that  are  required  throughout  the  lifecycle  of  the  process  to  bring  a  product  to  fruition.  By 
focusing  on  decisions,  this  literature  tends  to  be  broad,  borrowing  ideas  and  building  upon  them  from 
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many  different  academic  fields  such  as  engineering,  marketing,  finance,  or  operations.  One  of  the  more 


seminal  papers  in  this  field,  "Product  Development  Decisions:  A  Review  of  the  Literature,"  written  by 
Krishnan  and  Ulrich  [11],  reviews  a  large  number  of  previously  published  material  that  discusses  such 
things  as  projects,  program  management,  risk,  portfolio  management,  and  other  areas  that  are  essential 
for  developing  new  products.  Similarly,  Kahneman,  Tversky  and  Lovollo  [12-16]  have  made  significant 
contributions  to  product  development  by  studying  the  psychology  of  managerial  decision-making.  In 
these  papers,  a  recurring  theme  is  learning  to  manage  the  risk  and  uncertainty  that  may  exist  when 
leaders  are  presented  with  a  decision  about  a  product  in  development.  Furthermore,  decisions  in  these 
realms  tend  to  be  marked  with  over  optimistic  projections  and  managerial  biases  that  can  cloud  a 
decision's  real  outcome. 

Risk 

The  literature  reveals  some  theoretical  work  linking  risk  to  product  development  projects. 
However,  a  sampling  of  the  literature  shows  the  definition  and  meaning  of  risk  in  this  field  is  often 
muddled.  Among  the  general  meanings  of  risk,  there  are  competing  definitions  depending  upon  the 
perspective  of  the  various  disciplines  [3,  17-22],  However,  the  common  elements  of  these  definitions 
revolve  around  probabilistic  inputs  tending  to  uncertain  outcomes. 

In  product  development  literature,  several  kinds  of  specific  risk  are  enumerated,  such  as: 
schedule,  performance,  development  cost,  technology,  market,  and  business  risk  [23],  McManus  and 
Hastings  [24]  add  categories  of  risk  such  as:  disaster,  failure,  degradation,  market  shifts,  need  shifts, 
extra  capacity,  and  emergent  capabilities.  Miller  and  Lessard  [25]  enumerate  additional  kinds  of  risk, 
particular  to  megaprojects,  and  equally  applicable  to  DOD  Acquisition  efforts.  These  are:  program 
stability  risk;  economic  environment  risk;  and  optimism  risk.  There  are  even  the  process-oriented 
categories  of  risks  of  operational,  design,  manufacturing,  and  performance  according  to  Chase  [26], 
Finally,  let's  not  forget  interdependencies  which  can  comprise  a  distinct  category  of  risk  [19].  Lessard 
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and  Miller  [27]  further  caution  that  "risks  are  multidimensional  and  thus  need  to  be  unbundled  for  clear 


understanding  of  causes,  outcomes,  and  drivers." 

Keizer,  et  al  [28],  recently  addressed  risks  in  new  product  development  (NPD)  using  a  multi¬ 
dimensional  approach.  They  sought  to  demystify  the  various  kinds  of  NPD  risks  along  the  lines  of 
technological,  business,  and  organizational  risks.  They  developed  a  taxonomy  of  nearly  142  "risks" 
clustered  into  twelve  main  risk  areas.  These  risks  contain  three  variables  of  interest:  likelihood,  impact, 
and  ability  of  the  product  development  team  to  influence  the  risk  within  their  constraints.  These  twelve 
categories  are:  organization  and  project  management  risks;  commercial  viability  risks;  consumer 
acceptance  and  marketing  risks;  product  family  and  brand  positioning  risks;  manufacturing  technology 
risks;  product  technology  risks;  supply  chain  and  sourcing  risks;  trade  customer  risks;  competitor  risks; 
public  acceptance  risks;  intellectual  property  risks;  and  screening  and  appraisal  risks  [28], 

Keizer's  enumeration  of  risks  corresponds  nicely  with  Williams'  earlier  bibliography  of  research 
relating  to  project  risk  management  [29],  Among  the  risks  in  product  development  identified  were:  time 
risk,  cost  risk,  performance  risk,  and  the  contractual  aspects  of  risk  [30],  Notably,  Williams  [29]  also 
acknowledges  the  hand  of  multiple  disciplines  (Management  Sciences,  Operations  Research, 

Engineering,  and  Psychology/Decision  analysis)  in  shaping  the  concepts  of  risk  important  to  projects.  He 
further  proposes  adding  another  dimension,  predictability,  to  the  traditional  understanding  of  risk, 
impact  vs.  probability,  in  order  to  distinguish  between  the  outcomes  of  an  intrinsically  uncertain 
situation,  aleatoric  probability,  and  outcomes  relating  to  a  measure  in  belief  of  a  proposition,  epistemic 
probability.  This  observation  opens  the  door  to  understanding  risk  from  a  psychological  perspective. 
Kahneman  and  others  [12-14, 16,  31]  have  identified  the  notion  of  "framing"  as  a  way  for  us  to  take 
mental  shortcuts  in  dealing  with  complex  and  risky  issues  which  lead  decision  makers  to  discount 
extreme  events  because  the  probability  is  too  low  to  evaluate  intuitively. 
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In  essence,  there  are  nearly  as  many  kinds  of  risks  as  there  are  ways  to  describe  risk,  and  care 


must  be  taken  how  the  word  "risk"  is  defined.  There  is  general  agreement  in  the  literature  about  the 
kinds  of  risks  common  to  PD.  Effectiveness  of  risk  mitigation  activities,  however,  is  difficult  to 
demonstrate  because  it  depends  on  un-provable  counterfactuals  [32],  Managing,  measuring  and 
mitigating  risk  is  essential  to  PD,  but  no  clear  consensus  has  yet  emerged  regarding  how  to  do  that. 
Miller  and  Lessard  [25]  nevertheless  suggest  project  outcomes  are  the  most  appropriate  means  to 
measure  risk. 

Given  an  understanding  of  the  risks  facing  PD,  several  frameworks  exist  that  suggest  ways  to 
manage  risk  for  the  product  development  practitioner.  Most  of  them  follow  a  pattern  of  risk 
identification,  risk  analysis,  and  risk  disposition  to  describe  risk  management.  Examples  of  these  include 
references  by  Frame  [19],  the  Risk  Management  Guide  for  the  DOD  [33],  and  even  an  entry  in  Wikipedia 
[34],  There  are  also  many  other  frameworks  that  focus  on  a  particular  portion  of  these  generic  risk 
management  frameworks  and  advocate  using  various  tools  and  processes  for  that  specific  area  within 
risk  management.  Bresnahan  [35]  and  Hastings  &  McManus  [24]  for  example,  each  have  differing 
frameworks  for  approaching  risks  depending  on  the  task  at  hand  or  the  phase  (initial  concept, 
prototype,  final  design)  of  a  project  in  the  product  development  cycle.  Frame  [19]  elaborates  on  this  by 
saying  "the  risks  a  product  encounters  vary  dramatically  over  its  life".  For  example,  risks  encountered  in 
the  investment  phase  are  quite  different  in  content  and  impact  from  those  encountered  in  the  maturity 
phase. 

Oehmen  [36]  made  an  important  observation  about  risk  management  and  the  larger  product 
development  enterprise.  He  extended  the  common  risk  management  frameworks  beyond  their 
traditional  boundaries  by  adding  two  framework  elements  that  are  ignored  or  otherwise  assumed  by 
most  other  frameworks:  the  monitoring  of  risks  and  the  integration  of  risks.  The  "integration  of  risk" 
element  implies  methods  by  which  management  pulls  together  the  "big  picture"  regarding  overall  risk. 
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This  element  should  capture  the  cause  and  effect  network  effects  among  and  between  multiple 
projects.  "Monitoring  of  risks"  is  the  framework  element  describing  how  management  is  informed  of 
specific  project  risks.  He  documents  and  describes  over  fifty-seven  different  risk  management  methods 
and  where  they  are  most  applicable  to  be  used  (for  example,  FMECA).  However,  only  one  method  out 
of  the  fifty-seven  is  associated  with  the  integration  element.  This  method  is  called  "scenarios"  and  is 
mentioned  briefly  elsewhere  by  Miller  and  Lessard  [25],  No  explicit  method  is  identified  with  the 
monitoring  element.  Furthermore,  he  postulates  aggregation  as  a  method  to  use  at  the  enterprise  level 
to  manage  risk.  Shapira  [37]  agrees  with  his  assertion,  but  both  are  devoid  of  specifics.  Given  the 
above,  Oheman's  framework  seems  to  imply  a  link  to  portfolios  of  projects  and  their  management,  but 
no  further  elaboration  is  given. 

Portfolio  Management  strategies 

A  portfolio,  in  its  most  simple  definition,  is  simply  a  collection  of  items  brought  together  with  a 
common  characteristic.  From  a  product  development  perspective,  portfolios  refer  to  product 
development  projects  or  programs  that  have  something  in  common.  The  common  characteristic  can  be 
organizationally  based  (a  common  reporting  chain),  resource-based  (draw  upon  the  same  monies), 
personality  dependent  (the  same  manager),  or  any  other  combination.  Several  authors  have  suggested 
managing  product  portfolios  as  a  way  to  improve  the  overall  outcomes  of  product  development  in  terms 
of  the  bottom  line  to  a  company  or  meeting  the  emergent  market  needs,  etc.  [38,  39],  However, 
bringing  the  concepts  of  risk  and  portfolios  together  may  be  more  difficult  than  it  seems.  Managing 
product  portfolios  through  a  conceptual  risk  measure  common  across  the  products  in  the  portfolio  is 
seen  as  very  desirable;  however,  it  is  not  easily  done.  Shapira  [37]  noted  that  among  most  executives 
surveyed,  aggregation  of  risk  is  very  rarely  done  and  although  desirable,  is  usually  considered  too  hard 
to  do.  A  recent  RAND  study  agreed  with  both  sentiments  [40],  However,  Aloysius  [41],  in  discussing 
R&D  projects,  suggests  that  firms  can  consider  projects  collectively  and  that  risk  aggregation  helps  in 
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resource  decisions.  Using  aggregated  risk  and  portfolios  together  could  be  used  to  hedge  information 


uncertainty  when  making  decisions,  which  Krishnan  and  Ulrich  [11]  describe  as  the  essence  of  product 
development. 

But  aggregation  of  risk  is  not  the  only  way  to  consider  risks  in  a  portfolio.  Additional  evidence 
suggests  even  more  kinds  of  risk  are  at  play  when  considering  portfolios.  Fricke  and  Shenbar  [42]  show 
how  resource  allocation  and  flexibility  play  the  dominant  role  in  a  multi-project  environment,  consistent 
with  other  multi-project  management  research.  Pich,  Loch  and  De  Meyer  [43]  model  individual  projects 
as  activities  resulting  from  choices.  The  underlying  variable  is  the  information  provided  depending  upon 
the  information  environment.  Gutierrez  and  Paul  [44]  discuss  the  role  subcontracting  mechanisms  play 
on  project  success.  These  papers  touch  on  other  portfolio  implications  for  risk  (resource  allocation, 
flexibility,  choice,  information,  and  contracting  mechanisms)  not  previously  mentioned  in  the  examples 
of  risk  aggregation  that  exist  in  large,  complex  product  portfolios. 

Nevertheless,  the  benefits  of  using  portfolios  in  product  development  should  include:  having  a 
good  balance  of  projects,  promoting  a  mixture  of  possible  outcomes  and  a  mixture  of  projects  across  the 
product  development  lifecycle;  and  the  right  number  of  projects  in  development,  a  place  to  make 
go/no-go  decisions,  relating  to  managing  the  capacity  of  the  product  development  system  [25,  38,  45, 
46],  These  two  concepts  of  balance  and  capacity  suggest  other  risks  including  spanning  a  temporal 
dimension  that  portfolio  management  implicitly  should  handle  as  part  of  its  approach. 

Several  portfolio  management  tools  and  techniques  have  emerged  over  time  using  traditional 
project  financial  information  that  may  be  construed  to  include  risk  as  a  factor.  These  include  the 
Growth-share  matrix  (Boston  or  BCG  matrix)  [47],  the  GE  multi-factoral  analysis  (McKinsey  matrix)  [48], 
the  advantage  Matrix  (another  BCG  matrix)  [49],  the  Ansoff  Product-Market  Growth  matrix  [50]  and  the 
Contribution  Margin  Analysis  method  [51-55],  These  matrices  attempt  to  put  different  projects  into 
different  categories  to  simplify  managing  towards  the  benefits  of  portfolio  management  mentioned 
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earlier.  Cooper,  Edgett,  and  Kleinschmidt  [38]  report  that  among  product  development  firms, 
techniques  which  use  financial  indicators  (NPV,  i RR,  etc.)  are  the  least  effective  in  outcome  prediction 
and  control  compared  to  more  qualitative  methods  like  scoring  models  or  strategic  methods. 
Nevertheless,  these  are  often  the  most  employed,  perhaps  reflecting  management's  familiarity  with 
such  tools.  Management  dissatisfaction  with  these  financial-based  tools,  however,  remains  high  [38], 
The  authors  [38]  recommend  taking  a  balanced  approach  that  uses  as  many  of  these  tools  as  possible. 

Not  surprisingly,  the  risk  literature  and  practice  has  evolved  to  contribute  many  methods  to 
portfolio  settings  because  many  of  the  issues  faced  seem  to  be  just  extensions  of  those  seen  in  project 
risk  management.  Most  classical  engineering  and  operations  research  approaches  used  for  project  risk 
can  also  be  applied  to  a  portfolio  setting.  These  methods  tap  a  wide  spectrum  of  disciplines  and  use  a 
wide  variety  of  tools  and  processes,  ranging  from  simple  list-keeping  to  more  formalized  approaches. 
Simple  lists  and  matrices  such  as  those  advocated  by  Bettis  &  Hall  [56]  and  Fiegenbaum  &  Thomas  [57], 
bubble  diagrams  as  discussed  by  Cooper  [58],  dependency  matrices  as  discussed  by  Dickinson  [59], 
criteria  selection  [60],  and  using  value  vs.  variance  [61],  quantify  risk  in  portfolios  through  a  mix  of 
qualitative  and  quantitative  methods.  Nonetheless,  all  of  these  approaches  shy  away  from  "hard"  or 
"exact"  numbers  mainly  because  any  number  remains  difficult  to  interpret. 

Some  risk  aggregation  or  additive  methods  do  exist  that  may  be  applied  to  portfolios  in  the 
future.  Garvey  [62],  for  instance,  uses  an  index  to  measure  an  overall  system's  performance  risk  by 
normalizing  all  the  technical  performance  measures  within  a  project  and  then  adding  them  up  to  give  an 
overall  risk  index.  However,  no  portfolio  level  application  using  this  method  has  yet  been  noted. 
Bozeman  &  Rogers  [63]  use  a  simple  aggregation  of  the  number  of  articles,  patents,  and  algorithms 
resulting  from  a  portfolio  of  R&D  activity  to  indicate  the  risk  associated  with  that  portfolio,  but  its 
application  to  project  portfolios  seems  limited.  Parametric  comparison  of  similar  projects  using 
historical  data  is  also  a  form  of  aggregation.  However,  the  following  go  beyond  simple  mathematical 
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formulations.  One  such  method  advocated  by  Lovallo  [64,  65]  is  reference-class  forecasting  taken  from 


the  field  of  behavioral  psychology.  Another  method  by  Bearden  [66]  correlates  "complexity"  (a 
heuristic-defined  term  based  upon  various  system  attributes)  with  cost  and  schedule  of  projects  and 
finding  a  threshold  that  when  crossed  results  in  failure  of  projects. 

A  favorite  method  among  practitioners  to  compare  projects  is  adopting  multi-attribute  utility 
theory  (MAUT)  methods.  These  are  currently  being  used  for  many  portfolio  applications.  There  is  an 
entire  body  of  literature  devoted  to  these  methods,  including  extensions  to  portfolio  selection,  mostly 
drawing  from  operations  research.  For  example,  Levardy  &  Browning  [67]  use  the  notion  of  schedule 
risk,  cost  risk,  and  technical  performance  risk,  each  weighted  by  a  specific  value,  and  then  added 
together  to  denote  the  risk  of  a  project.  Extending  this  method  to  a  portfolio  of  projects  is  problematic 
because  comparing  dissimilar  risks  between  projects  is  difficult.  Aloysius  [41]  proposed  using  an 
expected  utility  framework  to  show  that  aggregation  of  risk  would  reduce  risk  aversion  for  the  efficient 
selection  of  joint  projects  by  a  consortium.  Browning  &  Eppinger  [68]  discuss  MAUT  methods  at  length, 
including  the  drawbacks  of  its  complexity  and  the  amount  of  data  required  for  accurate  modeling  of  risk. 
The  largest  limitation  noted  by  them  is  two-fold:  metrics  can  be  gamed,  and  the  choice  of  the  utility 
function  is  an  important  key  to  the  interpretation  of  results. 

More  sophisticated  approaches  may  include  the  use  of:  Real  Options  [69-71],  System  Dynamics 
[72,  73],  Shannon  Entropy  or  Information  theory  [74-77],  Model  Predictive  Control  [78,  79],  Control- 
theoretic  forms  [80],  and  Decision-theoretic  approaches,  but  none  are  being  used  exclusively  to  manage 
portfolios  of  projects  [31,  51,  52,  68,  81-88],  Several  of  these  methods  incorporate  the  use  of  triangular 
probability  distribution  functions  to  represent  worst  case,  most-likely,  and  best  case  risk  expressions, 
tacitly  acknowledging  the  uncertainties  that  exist  in  projects. 
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Enterprise  Risk  and  Portfolio  Execution 

Notably,  all  of  the  above  portfolio  frameworks  assume  clear  portfolio  choices  and  risks  that  are 
known  a  priori  and  do  not  and  cannot  account  for  day-to-day  uncertainties  and  emerging  risks  or 
opportunities  over  time.  The  only  way  to  account  for  such  uncertainties  and  changes  is  by  re-using 
these  tools  often,  usually  on  an  annual  or  semiannual  basis.  It  is  interesting  to  note  that  researchers 
have  devoted  the  greatest  measure  of  their  time  and  attention  to  the  selection  and  optimization  of 
project  portfolios.  Every  method  then  assumes  the  execution  of  each  portfolio  occurs  within  the  bounds 
of  the  original  assumptions.  However,  McDonough  &  Spital  [89]  reveal  a  different  perspective  of 
portfolios.  They  suggest  after  initial  portfolio  decisions  are  made,  the  execution  of  these  decisions,  the 
"how",  plays  a  great  role  in  determining  PD  success.  Granted,  individual  project  performance  does 
make  a  difference  to  the  overall  success  of  the  portfolio,  but  the  "actual  efficiency  of  project  portfolio 
management  has,  so  far,  been  a  rare  topic  of  study"  [90],  McNamara  &  Bromiley  [91]  agreed  and  noted 
there  is  a  pressing  need  to  "measure"  risk  as  decision  makers  use  it  in  a  portfolio,  while  Ruefli,  Collins,  & 
Lacugna  [92]  lament  the  decline  of  studies  looking  into  risk  at  this  level  of  analysis.  No  additional 
mention  or  examples  of  portfolio  execution  studies  were  found  beyond  those  cited  here. 

Stanke's  framework  [93]  for  high-performing  enterprises  defines  performance  of  the  enterprise 
as  a  combination  of  three  items:  alignment,  efficiency  of  execution  (agility),  and  effectiveness  of 
outcomes  (flexibility).  Agility  is  the  ability  of  an  enterprise  to  address  known  issues,  flexibility  is  the 
ability  to  address  unknown  issues,  and  alignment  is  the  behavior,  both  system  and  individual,  that 
enhances  agility  and  flexibility.  In  an  ideal  sense,  a  portfolio  is  successful  when  it  is  able  to  address 
known  and  unknown  issues  and  promote  strategic  behaviors.  Westerman  and  Hunter  [94]  outlined 
another  enterprise  framework  including  agility  as  an  enterprise  risk.  They  also  drew  a  distinction 
between  "Enterprise  risks"  (the  things  that  the  C-level  of  a  corporation  cares  about)  and  "risk  factors" 
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(the  things  that  are  managed  at  lower  levels,  including  individual  program  risks).  If  "Enterprise  Risk"  is 


assumed  when  discussing  "portfolio  risk,"  then  even  more  confusion  could  result. 

In  reflecting  upon  the  literature  reviewed  thus  far,  portfolios  should  be  a  mechanism  in  which 
whatever  is  defined  to  be  within  a  particular  portfolio  is  managed  alongside  the  other  portfolio 
members.  Implicit  in  this  is  broad  control  over  the  composition,  resourcing,  and  execution  of  all  items  in 
the  portfolio  by  the  portfolio  manager.  Further,  any  product  development  system  using  portfolios  that 
does  not  grant  such  far-reaching  capabilities  to  those  managing  the  portfolios  will  not  be  able  to  benefit 
from,  leverage,  or  measure  the  benefits  ascribed  to  product  portfolio  management.  Furthermore,  it 
appears  that  no  one  single  method  has  emerged  to  identify,  define,  or  measure  a  "portfolio  risk" 
measure  although  numerous  candidates  exist  which  in  some  combination  may  serve  as  useful 
surrogates  for  such  a  risk  measure. 

Enterprise  Acquisition  System 

Given  the  review  of  product  development,  the  coupling  between  risk  and  performance,  projects 
and  portfolios  and  the  interplay  among  all  of  these  underscores  the  likely  emergence  of  a  very  complex 
system.  A  thorough  examination  of  a  complex  product  development  system  such  as  the  one  used  by  the 
United  States  Air  Force  is  worthwhile  to  illustrate  the  capabilities  and  challenges  of  such  a  system.  The 
USAF  system  is  an  apt  candidate  for  a  closer  examination  due  to  its  large  acquisition  responsibilities,  its 
existence  within  a  larger  organization,  the  Department  of  Defense,  and  the  added  complexity  of  the 
system  due  to  the  USAF  being  a  governmental  entity.  As  noted  earlier  in  this  chapter  regarding  product 
development  in  general  and  the  emergence  of  risk  and  portfolios  as  key  players,  the  Department  of 
Defense  is  no  stranger  to  these  ideas  and  perceived  benefits. 

Recently,  a  Government  Accountability  Office  report  [95]  has  chastised  DOD  and  acquisition 
programs  in  general  because  they  "do  not  capture  the  requisite  knowledge  when  needed  to  efficiently 
and  effectively  manage  program  risks."  Not  only  has  risk  been  identified  by  the  GAO;  others  see  risk  as 
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a  major  driver  of  problems  in  product  development  and  as  an  area  ripe  for  improvement  [46,  96],  Miller 


and  Lessard  [25]  were  among  the  first  to  call  for  a  more  explicit  linkage  of  risk  to  the  management  of 
large-scale  engineering  projects.  The  outcomes  of  these  efforts  speak  for  themselves.  Biery  [97] 
documented  cost  and  schedule  growth  for  several  hundred  different  kinds  of  projects  and  mixed 
portfolios  over  the  course  of  several  decades.  He  found  that  in  large,  complex,  socio-technological 
systems,  cost  and  schedule  growth  was  more  often  the  rule  than  not.  For  example,  US  DOD  programs 
averaged  about  40%  schedule  growth  and  approximately  50%  cost  growth  [97],  From  an  enterprise 
perspective,  since  the  1970s,  total  budget  overruns  for  DOD  system  development  of  at  least  30%  have 
been  the  norm  and  are  increasing  [98],  Nevertheless,  drug  improvement  projects,  electricity  generation 
projects,  and  mining  projects,  to  name  a  few,  experienced  even  greater  cost  and  schedule  growth  than 
did  US  DOD  programs,  sometimes  up  to  500%  [97],  Similar  findings  using  different  data  sets  have  been 
produced  by  Flyvbjerg,  et  al  [99]  and  Miller  and  Lessard  [25], 

The  GAO  is  currently  encouraging  better  portfolio  management  for  the  DOD  as  a  way  to  deal 
with  the  inherent  risks  and  uncertainties  encountered  in  weapon  system  development  [100, 101]. 
Furthermore,  the  GAO  highlights  the  portfolio  impacts  of  risk  as  one  that  will  result  "in  a  reduction  of 
the  department's  buying  power"  [95],  Managing  risk  together  with  portfolio  management  is  now  the 
overriding  mantra  coming  from  the  GAO  [95,  98,  102]  and  also  RAND  [40, 103-105],  Both  organizations 
are  largely  silent  on  exactly  what  constitutes  portfolio  management  or  which  portfolio  management 
practices  in  particular  the  DOD  should  be  focusing  on,  but  they  often  cite  many  of  the  same  product 
portfolio  management  literature  previously  reviewed. 

To  provide  further  background,  within  the  DOD,  there  are  three  key  processes  that  interact  with 
one  another  in  weapon  systems  development.  Together,  these  are  coined  as  the  Big  "A"  of  Acquisition. 
All  three  of  the  processes  are  implemented  by  the  United  States  Air  Force  according  to  its  interpretation 
of  the  policy  guidance  received  from  the  DOD  [10].  The  first  of  these  processes  is  the  manner  by  which 
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the  end-user  or  the  war  fighter  determines  requirements  that  need  to  be  fulfilled  as  a  product  of  the 


acquisition  system.  This  process  is  called  the  Joint  Capabilities  Integration  and  Development  System 
(JCIDS).  The  next  process  is  the  one  by  which  the  Department  of  Defense  prioritizes  and  funds  all  of  its 
ongoing  activities.  It  is  called  the  Programming,  Planning,  Budgeting,  and  Execution  process  or  PPBE  for 
short.  The  last  process  is  called  Acquisition,  (coined  little  "a"  by  some),  also  governed  by  joint 
regulation,  and  has  been  the  subject  of  most  studies  and  direct  criticism  over  the  years  [3,  4],  The  Air 
Force  processes  are  different  in  their  form  and  operation  from  the  other  services.  A  more  detailed 
explanation  of  the  Air  Force  version  of  these  three  processes  follows  below.  For  one  of  the  most 
complete  and  detailed  examinations  of  the  overall  acquisition  process,  from  a  Defense  Department 
perspective,  including  a  short  modern  history  of  acquisition  in  defense,  please  see  the  CRS  report  for 
Congress  updated  on  June  18,  2008  [106],  The  AFIT  thesis  by  Elkins  [107]  also  contains  one  of  the  most 
thorough  reviews  of  historical  aspects  of  the  acquisition  of  weapon  systems  from  the  late-1700s  to  the 
present-day. 


Source:  Defense  Acquisition  Performance  Assessment  Report.  February  2006.  p.  4. 

Figure  2:  The  Total  Acquisition  System 


[106] 
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JCIDS 


JCIDS  is  governed  by  a  Chairman  of  the  Joint  Chiefs  Of  Staff  Instruction  3170.01E  that  lays  out 
the  overall  process  by  which  new  material  requirements  are  expressed,  prioritized,  and  inserted  into  the 
formalized  acquisition  system.  It  "involves  an  analysis  of  Doctrine,  Organization,  Training,  Material, 
Leadership  and  Education,  Personnel  and  Facilities  (DOTMLPF)  in  an  integrated,  collaborative  process  to 
find  gaps  in  war  fighting  capabilities  and  propose  solutions"  [10].  Several  levels  of  analyses  take  place  in 
the  early  JCIDS  process.  Most  times  this  process  generates  changes  in  policy  or  changes  in  the  use  of 
existing  items.  However,  when  a  material  need  is  identified,  it  kicks  off  a  whole  series  of  events  that 
culminate  in  the  final  development  and  acquisition  of  a  system  that  requires  the  interaction  of  JCIDS, 
PPBE,  and  Acquisition.  This  'series  of  events'  is  depicted  by  the  figure  below. 


JCIDS  AND  DEFENSE  ACQUISITION 
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JROC  -  Joint  Requirements  Oversight  Council 

DAB  -  Defense  Acquisition  Board 

ITAB  -  Information  Technology  Acquisition  Board 


Figure  3:  From  Chapter  1.3  of  the  Defense  Acquisition  Guidebook1 


1  JROC  =  Joint  Requirements  Oversight  Council;  AOA  =  Analysis  of  Alternatives;  IOC  =  Initial  Operating  Capability 
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The  decision-making  portion  of  JCIDS  and  the  Air  Force  application  of  JCIDS  are  remarkably 


similar  to  a  stage  gate  structure.  Over  a  period  of  time  as  an  idea  or  concept  matures  and  gains 
definition,  a  series  of  reviews  is  held  to  determine  if  the  concept  should  go  forward,  or  if  there  is  money 
available  to  fund  the  concept,  or  to  assess  risk  or  other  concerns  with  a  program.  Each  major  command 
is  given  the  latitude  to  determine  how  to  develop  and  select  the  needs  and/or  requirements  for 
consideration  across  the  Air  Force.  For  instance,  in  one  command,  the  process  is  very  formalized  as  a 
concept  goes  from  the  lowest  levels  of  the  departmental  organization,  from  the  originator  to  the 
division  chief  level  and  up  through  the  process  until  reaching  the  actual  General  running  the  MAJCOM. 
Once  completing  the  MAJCOM  hurdle,  the  stated  need  or  requirement  then  is  sent  out  into  the  at-large 
Air  Force  process.  The  Air  Force  process  is  structured  so  that  it  should  only  take  21  days  for  a  complete 
review  to  be  done  [108],  During  those  21  days,  all  of  the  other  MAJCOMs  and  interested  organizations 
are  given  the  opportunity  to  review  and  comment  on  the  original  MAJCOM's  idea  or  request  more 
information.  Built  into  this  process  are  ways  to  gather  and  resolve  comments  and  concerns  about  a 
MAJCOM's  idea.  A  dated  but  still  valid  description  of  the  process  in  an  older  form  was  described  by  an 
earlier  effort  [109], 
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Source:  Figure  A-2.  CJCSM  3170.01C.  May  1.  2007.  j1Q6j 

Figure  4:  Relationship  of  Strategic  Processes  with  JCIDS2 

The  previous  two  figures  give  some  insight  into  how  JCIDS  operates.  After  an  analysis  is 
performed,  several  types  of  documents  can  be  its  product.  The  first  document  is  called  an  "Initial 
Capabilities  Document."  This  document  is  used  by  the  acquisition  system  to  guide  the  development  of 
an  early  acquisition  program  culminating  in  a  stage  gate  review  called  "Milestone  A."  Another 
document  is  the  "Capability  Development  Document."  Any  associated  development  using  this 
document  as  a  guide  culminates  in  a  "Milestone  B  Decision."  Finally,  the  last  major  product  of  JCIDS 
would  be  a  "Capability  Production  Document."  This  document  outlines  the  requirements  for  the  final 
stages  of  development  of  the  material  solution.  The  culmination  of  any  development  activity  results  in  a 
Milestone  C  Decision  and  permission  to  proceed  to  a  final  decision  on  final  production,  fielding,  and 
sustainment. 

2  JCD  =  Joint  Capability  Document;  DCR  -  not  applicable 
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Scattered  throughout  this  process  are  several  analyses  and  dedicated  events  that  study  and 


analyze  proposed  concepts  versus  a  documented  need.  These  are  noted  simply  as  JCIDS  analysis  or  as  a 
more  formal  analysis  called  an  "Analysis  of  Alternatives"  or  may  be  just  a  refinement  of  previous 
analyses.  Between  the  analyses  events  and  the  approval  of  these  documents,  JCIDS  not  only  outlines 
the  process  by  which  these  documents  are  generated  and  approved,  it  also  allows  new  developments  to 
be  inserted  at  any  time  along  this  process  (and  into  Acquisition)  as  long  as  the  appropriate  requirements 
document  is  in  place. 

The  Air  Force  application  of  JCIDS  is  covered  by  a  series  of  Air  Force  policy  documents  and 
instructions.  The  most  relevant  is  AFI 10-601,  Capability  Based  Acquisition  [10].  The  following  figure 
shows  some  of  the  relationships  between  and  ties  to  the  Acquisition  system,  detailed  later  in  this 
chapter.  The  connections  between  JCIDS  and  the  financial  system  of  the  Air  Force  are  assumed  to  exist 
at  this  level  of  detail  and  are  not  relevant  to  the  discussion  at  this  point. 
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Figure  5:  Connections  between  JCIDS  and  Acquisition3 

Upon  closer  examination,  there  are  nuances  to  the  JCIDS  process.  For  instance,  the  Department 


of  Defense  exerts  some  authority  over  the  approval  of  requirement  documents,  especially  as  their  cost 


estimates  increase  or  have  high  visibility  or  high  interest.  The  highest  level  of  scrutiny  is  titled  "JROC 


Interest."  This  means  that  the  Joint  Requirements  Oversight  Council  (JROC),  consisting  of  the  Vice 


Chairman  of  all  of  the  armed  services,  must  approve  the  documents.  Typically,  these  are  reserved  for 


ACAT4 1  programs  and  a  few  ACAT  II  programs  -  but  they  reserve  the  right  to  approve  any  program  they 


are  interested  in.  A  discussion  about  ACAT  levels  occurs  in  Appendix  D.  The  second  category  is  called 


3  OSD  =  Office  of  the  Secretary  of  Defense;  JIC  =  Joint  Integrating  Concepts;  CBA  =  Capabilities-based  Assessment; 
JCB  =  Joint  Capabilities  Board;  KPPs  =  Key  Performance  Parameters;  LRIP  =  Limited-rate  Incremental  Production 

4  Acquisition  Category 
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"Joint  Integration."  These  are  mostly  those  that  have  some  joint  components,  such  as  software  or 
architectural  elements  shared  among  the  services.  In  these  cases,  the  AF  still  approves  them,  but  must 
also  ensure  the  rest  of  the  joint  community  knows  about  them.  The  last  category  is  called  "Joint 
Information."  These  are  typically  programs  that  are  only  done  by  one  service  and  clearly  fit  into  the 
roles  and  mission  of  only  one  service.  These  are  usually  ignored  by  the  rest  of  the  services.  Within  this 
discussion,  it  is  important  to  note  that  in  the  two  categories  that  the  AF  retains  approval  authority  on, 
the  level  of  the  approval  authority  changes  depending  upon  the  ACAT  level.  The  most  expensive  and 
visible  AF  programs  will  always  be  approved  by  the  Chief  of  Staff  of  the  Air  Force.  Other  types  of 
programs  will  be  approved  by  different  staff  elements  within  the  Headquarters  of  the  USAF.  The  table 
following,  taken  from  AFI  10-601,  shows  how  this  is  differentiated. 
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Table  1:  Table  of  Validation  and  Approval  Authority5 

Beyond  the  major  categories  used  for  programs  as  noted  above,  there  is  also  a  grey  area  in 
system  development  activities  where  changes  or  modifications  to  existing  programs  or  fielded  systems 
do  not  fit  into  any  of  those  previously  described  categories.  The  Requirements  process  has  guidelines  to 
assist  project  officers  determining  how  these  changes  are  implemented.  These  guidelines  are 
summarized  in  the  table  below  taken  from  AFI  10-601. 


5  AFROCC  =  Air  Force  Requirements  Oversight  Council;  CSAF  =  Chief  of  Staff  of  the  Air  Force;  A3/5  =  Combined  Air, 
Space  and  Information  Operations  with  Plans  and  Requirements;  AF/A5R  =  Requirements  Branch  of  A5 
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Modification 

Requirements 

Approval 

($)  Amounts 

Document 

Authority 

<  10%  of  AC  AT  II  Minimum  Thresholds  * 

& 

AF  Form  1067 

Lead  MAJCOM  &  PM 

<  $30M  total  expenditure  ** 

<  10%  of  AC  AT  II  Minimum  Thresholds  * 

AF  Form  1067  with 

& 

RCT  forKSAs  &  Attributes 

HQ  USAF/A5R 

>  $30M  total  expenditure  ** 

(use  CPD  RCT  format) 

>  10%  of  AC  AT  II  Minimum  Thresholds  * 

ICD,  CDD,  CPD 

See  Table  2.1. 

*  Consideration  must  be  given  to  both  RDT&E  and  procurement  amounts 
**  Total  dollar  amounts  are  based  on  FY  2000  constant  dollars 


Table  2:  Modification  Thresholds  (Financial  Thresholds)6 

Simply  put,  the  less  money  required,  the  less  formality  is  also  required.  However,  despite  the 
small  percentages  noted  above,  these  amounts  can  become  quite  substantial.  Smaller  amounts  can  be 
approved  by  the  Major  Command  (MAJCOM)  and  the  program  manager  for  the  acquisition  (PM).  Larger 
programs  receive  more  scrutiny  and  must  be  approved  at  the  HQ  level.  Beyond  a  certain  threshold, 
programs  must  follow  the  more  formal  and  proscribed  format  discussed  earlier. 

Finally,  there  are  some  additional  caveats  placed  upon  JCIDS  materials,  depending  upon  the 
community  that  will  be  the  recipients  of  the  new  materiel  solution.  The  following  table  highlights  these 
relationships. 


6  AF  Form  1067  =  Modification  form;  PM  =  Program  Manager;  RCT  =  Requirements  Crosswalk  Table;  RDT&E  = 
Research,  Development,  Test  and  Evaluation 
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Certification/ 

Validation 

JROC 

Interest 

Joint 

Integration 

Independent/ 

Joint 

Information 

Documents 

Threat  Validation 

DIA 

DIA 

Service 

JCD.  IC'D.  CDD.  & 
CPD 

Intelligence  * 

JS/J-2 

JS/J-2 

- 

JCD.  ICD.  CDD.  & 

CPD 

Insensitive 

Munitions** 

JS/J-8 

JS/J-8 

- 

CDD  &  CPD 

Interoperability 
&  Supportability 

JS/J-6 

JS/J-6 

- 

CDD  & CPD 

*  For  programs  that  consume,  produce,  process,  or  handle  intelligence  data 
**  Applies  to  munitions  programs  only 


Table  3:  Document  Certification/Validation  Authority7 

Each  of  the  different  types  of  documents  tend  to  take  different  amounts  of  time  to  approve 
depending  upon  how  many  stops  and  certifications  or  validations  are  required  to  proceed  to  the  next 
step.  The  Air  Force's  requirements  policy  organization,  for  example,  publishes  a  "regulatory  goal"  best 
case,  "realistic"  or  most  likely,  and  "pessimistic"  or  problematic  timeline  for  staff  officers  to  use  to  plan 
on  for  approval  actions  [110].  The  differences  in  schedule  outcomes  can  be  between  100  to  200  days 
between  best  case  and  worst  case  environments. 

Although  JCIDS  is  a  separate  process,  it  is  not  completely  isolated.  It  must  interact  with  the 
PPBE  as  well  as  the  acquisition  system.  These  interactions  can  be  both  trivial  as  well  as  very  important. 
For  instance,  some  of  the  forward  progress  as  defined  by  the  JCIDS  is  dependent  upon  activities  that  are 
completed  or  done  outside  of  JCIDS,  e.g.,  if  no  funding  for  an  analysis  activity  is  available,  then  the 
process  waits  until  money  is  obtained  from  another  process.  If  these  outside  activities  have  not  been 


7  DIA  =  Defense  Intelligence  Agency;  JS  =  Joint  Staff 
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accomplished,  the  system  must  either  wait  or  try  to  press  ahead  hoping  that  the  information  does  not 
change  along  the  way8. 

PPBE 

The  Programming,  Planning,  Budgeting  and  Execution  (PPBE)  process  is  how  the  entire 
Department  of  Defense,  including  the  Air  Force,  budgets  and  pays  for  all  activities.  The  PPBE  is  different 
from  the  other  processes  within  the  big  "A"  of  the  DOD  acquisition  system  in  that  it  is  a  continuous 
process  that  is  calendar-driven,  versus  the  others  being  event-driven.  Introduced  in  the  early  1960s  by 
Robert  McNamara,  the  PPBE  is  a  systematic  approach  to  the  planning,  budgeting  and  spending  of  funds 
for  the  Department  of  Defense  [10].  Over  time,  the  PPBE  has  undergone  many  changes  and  currently 
has  evolved  into  a  process  on  a  two-year  cycle,  preparatory  for  inclusion  into  the  President's  budget 
submission  to  Congress.  Practically,  this  means  four  different  budgets  are  in  the  "system"  at  any  given 
time.  In  walking  through  the  process  from  the  beginning,  the  first  year  of  this  cycle  is  spent  largely  at 
the  MAJCOM  level  planning  and  preparing  a  budget  and  budget  forecasts.  The  second  year  is  largely 
spent  reconciling  the  various  budget  submissions  from  the  different  MAJCOMs  into  a  coherent  single 
submission  from  the  Air  Force  that  the  Department  of  Defense  will  use  in  reconciling  and  creating  the 
overall  Department  of  Defense  budget  request  to  OMB.  The  third  year  is  when  Congress  debates  the 
proposed  budget  and  the  fourth  year  the  budget  is  being  executed  or  spent.  See  the  figure  below. 


8  Some  may  suggest  that  these  behaviors  are  actually  portfolio  behaviors  without  being  identified  as  such.  This  is 
true.  However,  there  is  a  concern  that  the  essence  of  portfolio  management  is  diluted  and/or  lost  in  the  multi¬ 
layered  and  semi-accountable  hierarchy  attached  to  the  aforementioned  processes  within  the  US  Air  Force. 
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PPBE  Timeline 


Oct 

Nov 

Dec 

Jan 

Feb 

Mar 

Apr 

May 

Jun 

Jul 

Aug 

Sep 

FY09-  30  SPG 


IPL 

A 


JPG 

"A 


PDMs 


PBDs 

FY09-13 


AF  GuidanceNSS 

A  A 

4-Star  Mtg 

A  !  D’s&l’s 

(baseline  !  Offsets 
review) 

Baseline 

Extension  1st  AFG 

A  A 


Panel  Prep 


bes/cp! 

Build  1 

CSAF  !  PR/BR 

a  : 

2nd  AFG  AFB  AFC  PBR  to  OSD 

A  A  A  Ap-  — 


Hearings  &  Staffer  Days 


Initial  Distribution  Planning 
Authorization  Marks  &  r  f 
Deliberations  oonT 


FY08 

FY07 

Initial  Distribution 


PB  to  Congress 

A 


Appropriation  Marks  &  r  * 

Deliberations  Budget 

Enacted 


Midyear 

Review 


Supplemental 


Close-out 


FY 

A 


Integrity  -  Service  -  Excellence 

Figure  6:  PPBE  Timeline 
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In  an  attempt  to  make  the  process  more  responsive,  several  years  ago  the  concept  of  an  "on" 


year  and  an  "off"  year  was  introduced,  where  during  the  off  year,  the  planning  and  budget  development 
would  be  abbreviated  to  address  only  major  changes  [10].  The  first  figure  shows  the  "on-year."  The 


second  shows  the  "off-year." 
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Typical  PPBE  Biennial  Cycle 

(On-Year:  FY04,  FY06,  FY08  etc.) 
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Figure  7:  "On-year"  PPBE  schedule 
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Typical  PPBE  Biennial  Cycle 

(Off-Year:  FY05,  FY07,  FY09  etc.) 
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Source:  Defense  Acquisition  Guidebook.  Chapter  1.2. 
[https://akss.dau.mi1/dag/Guidebook/IG_cl.2.asp#Figure2]. 
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Figure  8:  "Off-year"  PPBE  Schedule9 


9  PDM  =  Program  Decision  Memorandum 
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As  mentioned  earlier,  the  process  typically  "starts"  at  the  lowest  level  possible  -  that  of  a 


MAJCOM  planning  activity.  Oftentimes,  this  process  will  begin  six  months  or  more  prior  to  the  listed 
official  timetables.  And,  since  the  process  duration  is  at  least  two  years,  the  "start"  of  a  cycle  begins 
each  year.  During  an  "even"  year,  also  known  as  an  "on"  year,  a  "new  start"  program  may  be  put  into 
the  budget  request  (or  Program  Objective  Memorandum  (POM)).  During  the  "odd"  years,  also  known  as 
the  "off"  year,  no  "new  start"  may  be  made.  A  previous  version  of  the  process  allowed  the  services  to 
submit  an  amended  POM  or  "APOM"  but  this  has  been  eliminated  in  the  recent  years.  However, 
Program  Change  Proposals  (PCPs)  and/or  Budget  Change  Proposals  (BCPs)  may  be  made  to  address  fact- 
of-life  changes,  "broken  glass"  or  to  fix  things  gone  horribly  wrong. 

Within  the  Air  Force,  Air  Force  Instruction  16-501,  is  the  governing  document.  It  lays  out  how 
the  Air  Force  will  accomplish  the  building  of  the  proposed  Air  Force  budget.  A  corporate  planning 
process  consisting  of  councils  at  various  levels  is  used  as  a  way  to  review,  validate  and  approve  the 
various  budget  aspects  within  the  Air  Force  [112].  It  starts  off  at  lower  levels  in  forums  that  are  run  by 
Colonels  working  its  way  up  to  higher  and  higher  venues,  whose  membership  consists  solely  of  those  of 
senior  rank  such  as  four-star  Generals.  A  small  army  of  accountants  and  financial  managers  exist  in  the 
background  to  pull  all  the  pieces  together,  make  the  necessary  trades,  and  the  hard  decisions  to  be 
validated  in  these  forums.  The  following  figures  provide  some  context.  The  first  figure  shows  the 
overall  organizational  structure  for  the  budget  build.  The  next  figure  shows  how  one  MAJCOM  has  tried 
to  mimic  the  larger  Air  Force's  approach.  The  last  figure  shows  notionally  how  the  MAJCOM 
organization  integrates  with  the  Headquarters  AF  corporate  structure. 
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[112] 


Figure  9:  The  US  Air  Force  Corporate  Process10 


PEMS 


[113] 


Figure  10:  One  MAJCOM's  corporate  structure 


10  AF/CV  =  Air  Force  Vice  Chief  of  Staff;  SAF/FMB  =  Secretary  of  the  Air  Force  office  of  Financial  Management  and 
Budget;  SES  =  Senior  Executive  Service;  SPOC/SPRG/SAR  =  classified  financial  review  system  for  classified 
programs;  IPT  =  Integrated  Product  Team;  AF  CONOPS  =  Air  Force  Concept  of  Operation;  PEM  =  Program  Element 
Monitor 
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there  are  still  unresolved  issues,  these  are  known  as  Major  Budget  Issues  that  are  left  for  the  OMB  to 


resolve  as  they  prepare  the  President's  budget.  Of  course,  OMB  is  free  to  make  changes  to  reflect  the 
President's  priorities  and  after  submission  to  Congress,  the  Congress  often  makes  significant  changes  to 
the  budget. 


Concurrent  Program  and  Budget  Review  Process 
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Source:  DAUPPBES  Continuous  Learning  CourseCLB009.  [https://leam.dau.miL litml/clc/Clc.jsp],  ^ 


Figure  12:  Concurrent  Program  and  Budget  Review  Process12 

A  program  is  considered  "broken"  or  is  called  a  "disconnect"  if,  during  the  course  of  the  budget 
build,  it  no  longer  has  the  resources  to  execute  the  corporate  structure's  approved  program  plan  [111], 
An  "offset"  or  "bill  payer"  is  a  program  that  has  been  identified  from  which  monies  can  be  taken  to  fix 
broken  programs--a  program  of  lower  priority  than  the  one  needing  the  funds.  An  "initiative"  is  a 
program  that  is  appearing  for  the  first  time  and  needs  to  be  funded  or  reflects  an  increase  in  scope 
(requirements  growth)  from  a  previous  budget.  This  could  also  be  considered  a  new  start,  if  a  few  other 
threshold  criteria  are  met.  Programs  that  are  considered  a  new  start  also  have  considerable  additional 
documentation  required  by  Congress  before  any  such  program  will  be  authorized. 


OMB  =  Office  of  Management  and  Budget;  OSD  =  Office  of  the  Secretary  of  Defense;  SVC  HQs  =  Service 
Headquarters 
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As  mentioned  earlier,  there  is  a  small  army  of  dedicated  people  that  are  involved  in  the 


functioning  of  the  PPBE.  The  most  visible  member  is  called  a  PEM,  or  program  element  monitor.  The 
name  comes  from  the  individual  line  item  in  a  program  which  is  called  a  program  element.  These 
program  elements  are  more  detailed  breakouts  of  spending  activity  that  will  occur  and  can  be  reserved 
for  multiple  programs,  a  single  program,  or  even  a  single  activity.  It  is  the  PEM's  responsibility  to  keep  in 
close  contact  with  representatives  from  JCIDS  as  well  as  from  the  acquisition  system.  The  user 
community,  represented  by  officers  and  employees  working  within  JCIDS,  have  a  vested  interest  to  stay 
on  top  of  the  state  of  the  funding  of  their  project  or  program  as  it  goes  through  the  system.  From  the 
acquisition  perspective,  the  PEM  is  the  person  to  whom  the  program  manager  is  in  constant  contact  to 
report  that  funds  are  being  spent  according  to  plan  as  well  as  to  keep  the  PEM  informed  of  any  issues  or 
problems  that  might  be  experienced  by  the  program.  These  issues  or  problems  might  require  additional 
monies,  or  monies  to  be  shifted  to  different  time  periods  to  accommodate  changes  in  schedule,  scope, 
or  other  issues.  Such  shifting  of  monies  can  easily  result  in  a  program  becoming  broken,  something  that 
a  PEM  does  not  want  to  see  happen.13  A  PEM  also  does  not  want  to  see  his  or  her  program  become  a 
source  of  money  or  an  offset  for  paying  bills.  The  PEM  has  the  incentive  to  maintain  the  monies  that 
have  been  previously  allocated  according  to  previously  approved  plans  for  a  given  program  or  system 
for  which  he  or  she  has  responsibility.  A  lot  of  deal-making  and  "horse-trading"  occurs  between  PEMs 
to  keep  burdens  low  and  avoid  some  of  the  required  documentation--these  deals  are  often  brokered  by 
others  ranging  from  folks  within  JCIDS  to  those  within  Acquisition. 14 

13  The  attitudes  or  desires  of  a  PEM  are  given  here  as  part  of  the  description  of  the  PPBE.  They  are  not  necessarily 
documented  but  are  listed  here  anyway  in  order  to  fully  explain  the  operations  of  the  system.  The  source  of  this 
information  is  based  upon  the  author's  experience  and  in  fact  is  corroborated  by  interviews  reported  on  in  a  later 
chapter  of  this  work. 

14  Again,  the  behaviors  reviewed  in  this  section  could  be  construed  as  portfolio  behaviors.  However,  these 
behaviors  lack  the  accountability  and/or  strategic  or  "portfolio-level"  thinking  that  would  be  expected  from  a 
portfolio  management  system. 
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It  is  important  to  note  that  throughout  the  process,  and  especially  during  each  budget  build,  the 


process  essentially  is  considered  starting  from  a  blank  sheet.  This  means  that  each  and  every  program 
must  re-justify  its  funding  and  its  existence  every  year  or  face  being  put  on  the  chopping  block.  This 
goes  for  well  established,  important  programs,  as  well  as  for  relatively  obscure  or  new  programs  in  the 
system.  Furthermore,  this  re-justification  occurs  in  multiple  places  at  multiple  levels  in  the  system 
because,  at  each  level  of  review,  a  program  can  be  questioned  again,  and  the  justification  process  starts 
anew. 

Just  as  programs  are  constantly  scrutinized,  at  every  level  of  the  process  exists  the  opportunity 
for  insertion  of  new  programs,  additional  spending,  etc.  Some  of  this  comes  from  the  commander's 
prerogative  to  exert  influence  on  the  budget-commander's  at  every  level  will  do  this-as  well  as 
expressed  opinions  from  civilian  leadership.  Programs  with  the  Chief's  or  the  Secretary's  interest  usually 
emerge  unscathed  from  the  process  outlined  above. 

Finally,  at  every  level  of  command,  usually  there  is  an  overhead  cost-affectionately  called 
"taxes"-that  each  program  must  pay.  This  means  that  an  approved  budgeted  amount  is  not  going  to 
get  to  the  program.  It  will  always  be  less  that  what  was  budgeted. 

During  the  execution  year,  the  PEMs  are  interested  in  how  well  the  money  is  being  spent.  There 
is  an  emphasis  placed  upon  rates  of  obligation15and  expenditure16.  OSD  usually  sets  goals  depending 
upon  the  type  of  money  being  spent  that  programs  try  to  meet  during  the  year.  If  they  fail  to  do  so  or 
spend  money17  too  quickly,  a  program  may  be  scrutinized  excessively  as  a  candidate  to  be  a  bill-payer. 

15  Obligation  means  the  government  has  committed  to  spend  the  money;  exercised  a  contract  option;  awarded  a 
bid/contract,  etc. 

16  Expenditure  is  when  the  money  is  actually  dispersed  from  the  Treasury. 

17  Moneys  in  the  Air  Force  often  come  in  different  "colors."  A  color  is  simply  a  category  of  money  that  must  be 
spent  a  certain  way.  Some  money  can  only  be  spent  on  development  items  over  a  two  year  period.  Other  money 
can  only  be  spent  on  operations  and  must  be  spent  completely  each  year.  So  depending  upon  the  "color"  of  the 
money,  the  length  of  time  to  spend  the  money  may  be  different  as  well  as  what  the  money  may  be  spent  on  at  all. 
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It  is  in  the  PEM's,  and  almost  everyone's,  interest  to  spend  money  quickly-but  not  too  quickly-over  the 


course  of  the  year. 

Since  PEMs  are  so  closely  tied  to  financial  matters,  they  are  often  the  first  stop  for  those  looking 
for  bill  payers.  A  PEMs  job  is  often  spent  doing  "budget  drills"  which  often  explore  different  scenarios  in 
an  attempt  by  the  corporate  structure  to  stretch  dollars  farther  [111],  During  these  drills,  the  PEM  is 
usually  totally  dependent  upon  the  information  they  can  get  from  the  acquisition  system  -  since 
members  of  the  acquisition  system  are  charged  with  the  day  to  day  operation  of  the  program. 

However,  the  time  available  for  a  response  is  usually  very  small-usually  less  than  4  hours-since  the 
PEM  has  a  deadline  himself  that  has  to  be  met. 

Politics  has  been  mentioned  previously  in  how  it  can  inject  turbulence  into  the  plans  and 
activities  of  many  programs.  Most  people  usually  think  of  Congress  or  Generals  exerting  influence 
within  the  system.  However,  the  DOD  is  part  of  the  Executive  Branch  of  government  and  over  an 
Administration's  term,  the  priorities  within  the  DOD  Budgets  are  shaped  more  here  than  anywhere  else. 
The  following  figure  illustrates  this  idea. 
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Refine  strategy  and 
programs 
SPG/JPG— full 

FY10  POM 


OFF-Year 

Fine  tune.  Make  only  essential  changes 
to  Programs/Budget:  FY09  APOM 


Four  Years  in  Administration  Life-cycle 


[in] 


Figure  13:  PPBE  Timing18 

With  this  understanding,  a  pattern  of  how  and  why  certain  decisions  are  made  within  DOD 


financial  priorities  emerges.  All  that  remains  is  to  execute  the  plans  that  are  reviewed  and  approved.  It 
also  indicates  how  even  in  a  long,  drawn  out  cycle,  there  are  ways  to  make  adjustments  when  the 


political  needs  demand  it. 


Acquisition 

This  process  describes  how  the  military  actually  executes  the  development  and  sustainment  of 


its  systems.  The  process  is  governed  by  Department  of  Defense  Instructions,  the  Federal  Acquisition 


Regulations  and  other  laws.  In  this  subsection,  the  structure  of  Acquisition,  the  people,  and  the 


18  APOM  =  off-year  Program  Objective  Memorandum;  QDR  =  Quadrennial  Defense  Review;  SPG  =  Strategic 
Planning  Guidance;  JPG  =  Joint  Planning  Guidance 
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governance  of  the  process  will  be  examined.  An  overview  of  some  of  the  studies  and  recommendations 


for  this  system  will  be  presented  in  Appendix  A. 

The  DODI  5000  series  of  instruction  is  focused  primarily  on  systems  acquisition  in  the  DOD.  As 
noted  earlier  by  the  DAPA  Report,  this  system  has  received  a  lot  of  scrutiny  and  been  the  subject  of  a  lot 
of  criticism  [3],  As  noted  by  DAPA,  the  system  typically  has  two  or  three  major  revisions  per  decade. 

The  most  recent  was  implemented  in  December  2008.  This  report  is  based  upon  the  pre-2008  revision. 
Within  the  Air  Force,  AFI  63-101  lays  out  the  structure  and  governance  of  the  process. 

The  following  diagram  shows  the  acquisition  system.  It  is  broken  up  into  five  distinct  elements, 
and  has  several  milestones  and  important  reviews  built  into  the  system.  It  also  indicates  how  new  ideas 
or  things  are  inserted  into  the  acquisition  system  can  come  in  at  any  of  the  three  milestones  from 
outside  of  the  process.  Milestone  B  is  considered  a  program  start  and  that  is  the  point  in  the  PPBE  it  is 
acknowledged  to  be  a  program  as  well.  This  is  when  the  program  receives  its  individual  program 
elements  or  budgeted  line  item. 


Process  entry  at  Milestone  A.  B.  or  C 
Entrance  criteria  ivet  before  entering  phase 

Evolutionary  Acquisition  or  Single  Step  to  Full 
Capability 
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Figure  14:  An  Overview  of  the  Acquisition  System19 


19  IOT&E  =  Initial  Operational  Test  and  Evaluation;  FRP  =  Full-Rate  Production 
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Each  service  is  given  latitude  to  define  and  develop  its  own  implementation  of  the  acquisition 


system.  As  noted  earlier,  AFI  63-101  outlines  the  process  by  which  the  Air  Force  has  implemented  the 


acquisition  system.  It  is  called  capabilities-based  acquisition.  The  following  figure  shows  how  the  Air 


Force  implementation  of  both  the  requirements  system  and  the  acquisition  system  relates  to  the 


approved  Department  of  Defense  system. 
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Operation  of  Capabilities  Based  Acquisition  System  (AFI  63-101)  [  [108] 

Figure  15:  Overlay  of  Acquisition  and  Requirements  processes20 
Regarding  the  execution  of  the  acquisition  system,  the  process  in  the  Air  Force  is  run  by  Air 


Force  Materiel  Command  (AFMC),  with  the  exception  of  space  acquisition  activities,  which  is  run  by  Air 


Force  Space  Command.  Most  of  the  Air  Force's  scientists  and  engineers  belong  to  AFMC.  The  command 


has  responsibility  for  several  product  centers  such  as  the  Electronic  Systems  Center  at  Hanscom  Air 


Force  Base  or  the  Aeronautical  Systems  Center  at  Wright  Patterson  Air  Force  Base.  Acquisition  activities 


are  done  at  these  centers,  according  to  their  area  of  expertise.  The  command  is  also  responsible  for  the 


20  FSA  =  Functional  Solutions  Analysis;  RSR  =  Requirements  Strategy  Review;  MDA  =  Milestone  Decision  Authority; 
ADM  =  Acquisition  Decision  Memorandum;  TDS  =  technology  development  strategy;  ISP  =  integrated  support  plan; 
DAB  =  Defense  acquisition  Board;  COA  =  courses  of  action;  DRR  =  design  readiness  review;  FRP  =  full  rate 
production 
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Air  Force  Research  Laboratories,  which  deal  with  technology  development  and  technology  transitioned 


to  systems  and  development.  Finally  the  command  is  also  responsible  for  air  logistics  centers  such  as 
Ogden  Air  Logistics  Center,  where  routine  maintenance  and  modifications  are  done  or  managed  on 
already  fielded  systems.  Air  Force  Material  Command,  in  essence  has  a  cradle-to-grave  responsibility  for 
Air  Force  systems.  Air  Force  Space  Command  has  the  same  kind  of  responsibility  for  space  systems,  with 
a  Product  Center  at  Los  Angeles  Air  Force  Base,  but  collaborates  with  AFMC  on  many  other  aspects  of 
acquisition,  such  as  laboratories  and  logistics  centers.  The  remaining  discussion  on  acquisition  will  focus 
mainly  on  the  AFMC  organizational  construct.  The  space  acquisition  organizational  construct  is  not 
different  enough  to  warrant  any  further  specialized  treatment. 

Acquisition  authority  flows  through  the  Secretary  of  the  Air  Force,  who  has  a  specialized  staff 
dealing  with  nothing  but  acquisition.  In  some  respects,  there  is  a  dual  reporting  structure  that  exists. 

For  instance,  the  facilities,  people  and  other  resources  are  provided  by  Air  Force  Material  Command. 
However,  the  authority  to  procure  or  develop  a  new  weapon  system  comes  through,  the  Secretary  the 
Air  Force  and  his/her  acquisition  staff. 

As  part  of  many  of  the  acquisition  reform  efforts,  Congress  demanded  a  more  professional 
acquisition  workforce,  whether  civil  servants  or  uniformed  personnel.  Under  the  Defense  Acquisition 
Workers  Improvement  Act,  acquisition  personnel  are  required  to  be  trained  and  maintain  competency 
in  their  specialization  and  particular  job  functions.  Levels  of  proficiency  and  certification  are  awarded  to 
employees  who  over  time  receive  both  experience  and  training  to  master  the  requirements  of  their 
particular  job  functions.  Additionally,  recent  requirements  have  mandated  that  program  managers  of 
major  programs  must  remain  in  their  position  until  the  system  in  development  reaches  its  next 
milestone.  All  these  improvements  are  designed  to  ensure  continuity  and  minimize  disruption  in  the 
development  of  systems. 
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The  overall  governance  of  the  process  begins  at  the  DOD  level,  and  authority  is  delegated  from 


there.  Service  Acquisition  Executives  bear  the  responsibility  for  the  Secretary  of  the  Air  Force  to  ensure 
that  programs  are  being  developed  in  accordance  with  current  law  and  on  schedule,  and  practicing  good 
financial  management.  Program  Executive  Officers  are  responsible  for  multiple  programs,  and  these 
people  delegate  acquisition  responsibility  to  lower  levels,  until  ultimately  the  authority  is  at  the  level  of 
a  program  manager.  The  Air  Force  recently  adopted  a  organizational  structure  that  causes  the  military 
organization  of  wings,  groups,  and  squadrons  to  be  adopted  to  the  acquisition  workforce.  Practically 
speaking,  what  this  means  is  that  the  PEO  is  usually  the  center  commander  and  has  wing,  group,  and 
squadron  commanders  working  for  him  or  her.  Program  managers  belong  to  individual  squadrons. 
Although  there  may  be  two  or  three  layers  of  management  from  a  military  chain  of  command 
perspective  between  the  PEO  and  the  program  manager,  the  Air  Force  gets  around  this  requirement  by 
stripping  various  commanders  of  acquisition  authority  so  that  there  is  no  conflict  between  the 
requirement  of  three  levels  of  organizational  separation  between  a  program  manager  and  a  PEO. 
Program  managers  spend  their  time  working  mostly  with  the  PEM  in  the  financial  system  and 
requirements  officers  with  the  major  command  that  is  developing  the  system.  The  military  chain  of 
command  within  the  program  management  process  often  concerns  itself  with  coordinated  answers  to 
various  requests  for  budgets  or  for  budget  drills  or  for  "what-if  scenarios"  so  that  everyone  from  top  to 
bottom  of  the  organization  is  using  the  same  points  of  reference  and  information. 

The  terminology  of  portfolios  is  often  bantered  about  and  used  in  various  contexts  within  the 
Air  Force.  The  PEO  often  talks  about  the  portfolio  of  programs  that  he  or  she  manages  as  well  as 
different  kinds  of  portfolios  that  might  be  platform-based  such  as  the  portfolio  of  F-16s,  or  a  portfolio  of 
different  product  types  such  as  aircraft  or  space  or  cyber.  Additionally,  the  portfolio  terminology  has 
also  been  applied  at  low  levels  to  describe  the  bundling  or  the  collecting  of  different  reporting 
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responsibilities  to  a  single  individual  based  on  the  different  programs  that  are  part  of  that  person's 
organization. 

During  the  year  the  program  manager  is  often  required  to  report  the  progress  that  the  program 
is  making  in  its  development.  This  happens  in  multiple  ways.  One  is  through  the  Monthly  Acquisition 
Report,  which  is  implemented  in  the  System  Metric  and  Reporting  Tool,  otherwise  known  as  "SMART." 
Then  there  are  additional  special  reviews,  called  for  instance,  "the  spring  review"  or  "the  fall  review," 
where  in  particular,  the  financial  execution  of  the  programs  is  scrutinized.  It  is  at  these  reviews  where 
monies  can  be  redirected  by  higher  headquarters  to  take  care  of  issues  elsewhere.  A  great  deal  of  effort 
is  put  into  preparing  for  these  reviews  so  that  a  program  puts  its  best  foot  forward  in  order  to  mitigate, 
as  much  as  possible,  the  likelihood  of  funds  being  redirected.  If  a  program  is  in  need  of  money,  it  is  also 
a  good  time  for  a  program  to  make  the  best  case  possible  for  why  it  should  receive  money  from  other 
programs  and  have  a  detailed  plan  on  how  the  money  will  be  spent  over  time.  In  theory,  at  these 
reviews,  the  impact  of  the  decisions  that  are  made  is  looked  upon  from  a  portfolio  perspective  and  not 
just  at  the  impact  to  the  program  in  question. 

Contractors 

Private  industry  or  contractors  play  an  important  part  in  the  overall  acquisition  of  systems.  They 
are  either  working  within  the  system  as  trusted  agents  of  the  government,  or  they  are  performing  for 
the  government  a  service,  or  delivering  a  product  according  to  the  terms  of  the  contract  that  they  have 
signed.  For  the  purpose  of  this  dissertation,  contractors  will  be  assumed  to  be  those  that  are  in  a 
contractual  relationship  with  the  government  to  deliver  a  product  or  service  and  are  not  considered 
services  and  technical  assistance  or  in  a  trusted  relationship.  In  general,  contractors  have  won  a 
contract  in  a  competitive  relationship  or  because  they  are  the  only  source  for  the  expertise  or  the 
material  that  is  needed  by  the  government.  They  are  driven  by  the  profit  motive  and  are  incentivized  to 
deliver  according  to  the  terms  of  the  contract. 
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Much  has  been  written  about  the  attempts  in  acquisition  reform  to  better  incentivize  and  align 


the  reward  structure  for  contractors  working  in  acquisition.  There  are  many  different  contractual 
relationships  that  can  be  entered  into  ranging  from  cost  reimbursements  all  the  way  through  firm-fixed 
price  with  an  award  fee.  Most  of  these  contractual  relationships  deal  with  the  degree  of  risk  that  the 
government  is  accepting  or  that  the  firm  is  willing  to  accept.  In  the  past,  there  have  been  some  abuses 
in  the  system  and  laws  and  policies  have  been  put  in  place  to  try  to  rectify  the  situation. 

However,  a  set  of  the  more  vexing  issues  that  contractors  deal  with  are  the  behaviors  of  the 
other  pieces  of  the  system.  War  fighters  often  want  to  insert  new  requirements  or  new  ideas  into  the 
system  and  the  contractor  tries  to  be  responsive  to  the  desires  of  the  customer.  The  acquisition  system, 
on  the  other  hand,  may  not  have  approved  the  additional  scope  of  work  or  the  new  things  being  put 
into  the  system.  And  so  oftentimes  the  contractor  is  left  holding  the  bag  or  guessing  what  to  do. 
Additionally,  sometimes  things  happen,  not  according  to  schedule.  Such  a  scenario  may  easily  exist 
where  a  contract  type  has  been  improperly  used  for  the  type  of  risk  involved,  e.g.  a  contractor  can  find 
themselves  in  a  situation  that  carries  far  too  much  risk  than  ought  to  be  carried  by  the  contractor. 
Another  scenario  is  that  they  run  out  of  money  to  do  the  work  that  they  have  agreed  to.  Sometimes 
running  out  of  money  is  a  function  of  being  too  competitive  in  the  bidding  process  and  undercutting 
what  they  could  actually  do,  or  it  can  be  a  consequence  of  unexpected  and  unexplained  problems  that 
arise  during  the  course  of  the  development  system.  Project  management  literature  is  full  of  all  kinds  of 
examples  of  how  to  deal  with  risk  and  uncertainty,  as  well  as  project  planning  and  execution.  The 
contractors  use  these  methods  and  skills  to  the  best  of  their  abilities  while  working  within  the  peculiar 
constraints  of  the  government  system.  Sometimes  these  systems  clash  and  contractors  usually  have  to 
make  the  process  work  regardless.  In  particular,  this  clashing  occurs  in  the  internal  portfolios  that  a 
company  has  and  the  way  that  individual  programs  are  staffed  or  resourced  accordingly. 
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Modeling  and  Analysis 

Considering  the  topics  discussed  in  this  literature  review,  an  important  step  to  consider  is  how 
to  represent  the  system  and  by  what  means  the  system  should  be  studied  in  greater  detail.  There  are 
different  ways  to  study  a  system  of  interest.  The  following  figure  illustrates  this  idea. 


Ways  To  Study  A  System* 


*  Simulation,  Modeling  &  Analysis  (3/e)  by  Law  and  Kelton,  2000,  p.  4,  Figure  1.1 


[114] 


Figure  16:  Ways  to  Study  a  System 

Considering  the  area  of  interest,  experimenting  with  the  actual  system  can  quickly  be  ruled  out 
for  various  reasons,  which  would  include  lack  of  time,  money  and  resources.  Therefore  a  logical  next 
step  is  to  explore  developing  a  model. 

A  seminal  piece  of  literature  authored  by  Browning  [18]  pulls  together  the  concepts  of  modeling 
and  product  development.  According  to  Browning  "a  model  is  an  abstract  representation  of  reality  that 
is  built,  verified,  analyzed,  and  manipulated  to  increase  understanding  of  that  reality.  Models  can  reside 
in  the  mind  (mental  models)  or  be  codified"  [18].  In  this  paper,  the  authors  indicate  that  although  a 
great  deal  of  literature  exists  on  process  modeling,  there  is  not  a  lot  of  literature  on  process  modeling 
directly  related  to  product  development.  However,  they  do  summarize  a  few  of  the  key  fundamental 
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propositions  that  "form  the  basis  of  product  development  process  modeling  theory"  [18].  Additional 


insights  include:  because  product  development  processes  can  sometimes  be  ambiguous,  full  of 
uncertainties  and  interdependencies,  product  development  processes  are  extremely  complex  and 
challenging  to  model;  processes  can  be  better  understood  by  examining  the  constituent  parts  of  the 
process  and  their  interactions;  and  the  best  a  model  can  do  is  approximate  reality-it  will  never  be 
completely  correct  [18]. 

Still,  the  model  needs  to  be  characterized  to  best  determine  how  to  analyze  or  manipulate  the 
model.  Some  of  the  questions  that  should  be  asked  include:  does  the  model  contain  stochastic 
components?  Is  time  a  significant  variable?  Does  the  system  state  evolve  continuously  or  at  only 
discrete  points  in  time?  [114].  Answering  these  questions  will  help  lead  to  an  appropriate  form  of 
analysis. 


Model  Taxonomy 


discrete-event  simulation 


[114] 


Figure  17:  A  Model  Taxonomy 
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A  quick  example  of  a  deterministic  model  that  is  also  dynamic  and  continuous  would  be  a  model 


of  Newton's  cooling  law.  An  example  of  something  that  is  stochastic,  dynamic  and  continuous  would  be 
a  model  of  a  pizza  oven  with  a  random  door  opening  and  closing  [114]. 

Park  [114]  recommends  that  when  developing  a  model,  there  are  three  different  model  levels. 
The  first  level  is  conceptual  in  nature  when  the  model  is  at  a  very  high-level  of  abstraction  and  still 
contains  ambiguity.  The  next  level  is  called  the  specification  level.  This  is  defined  by  putting  the  model 
on  paper  and  may  involve  equations  or  pseudocode.  The  last  level  is  called  the  computational  level, 
where  the  model  is  either  turned  into  a  computer  program  or  uses  a  programming  language  for  further 
analysis  [114]. 

Choosing  a  framework  in  which  to  build  a  model  oftentimes  determines  the  type  of  analysis  that 
is  done.  For  instance,  within  product  development,  applying  system  dynamics,  design  structure 
matrices  (DSMs),  or  queuing  theory  as  a  framework  are  viable  environments  to  build  a  model  [18,  23, 

68,  84,  115].  Other  models  can  be  spreadsheet-based  or  can  take  advantage  of  statistical  theories  such 
as  Monte  Carlo  simulation  by  using  specialized  software  such  as  Crystal  Ball  or  <®  Risk  [116].  Any  theory 
or  method  that  might  be  used  to  gain  insight  or  better  understanding  of  a  process  would  be  considered 
an  appropriate  framework  for  use. 

As  mentioned  earlier  a  model  can  lead  to  an  analytical  solution  or  can  be  simulated.  Depending 
upon  the  model,  there  are  some  technical  attractions  to  simulation.  A  simulation  has  the  ability  to: 
compress  or  expand  time;  control  sources  of  variation;  stop  and  review;  and  restore  a  system  state 
[117].  Furthermore,  simulation  can  help  avoid  errors  in  measurement,  facilitate  replication,  and  the 
modeler  controls  the  level  of  detail  [117],  There  are  all  kinds  of  simulation  software  packages  on  the 
market  today  that  the  modeler  can  choose  from.  These  come  with  different  features  and  are 
oftentimes  tailored  to  specific  applications  of  the  theory  or  thing  being  simulated  [118]. 
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One  of  the  last  things  required  to  finish  building  a  model  of  any  kind  is  the  verification  and 


validation  of  that  model.  Verification  simply  helps  answer  the  question  if  the  model  was  built  correctly. 
In  other  words,  the  computational  model  should  be  consistent  with  the  specification  model  [114]. 
Validation,  on  the  other  hand,  answers  the  question  if  the  right  model  was  built.  In  other  words,  the 
computational  model  should  be  consistent  with  the  system  being  analyzed  [114].  In  both  cases, 
interactive  graphics  can  prove  to  be  a  valuable  part  of  the  verification  and  validation  of  the  model  [114]. 

Summary  of  Literature  Review  -  Key  Take-aways 

This  chapter  has  looked  at  the  product  development  literature  with  respect  to  many  of  the 
managerial  aspects  of  developing  new  systems.  Looking  through  this  very  specific  lens,  considering  the 
ideas  of  risk  and  its  importance,  coupled  with  the  notion  of  portfolios  in  product  development,  suggests 
another  way  to  look  at  the  larger  picture  of  multiple  development  activities  occurring  across  an 
enterprise.  Furthermore,  product  development  enterprises  contain  a  great  deal  of  complexity  with 
multiple  processes  operating  at  once.  Within  the  Department  of  Defense,  and  in  particular  using  the  Air 
Force  as  a  surrogate,  the  literature  has  shown  how  the  Air  Force,  over  time,  has  tried  to  adopt  much  of 
the  literature  related  to  product  development  and  best  practices  such  as  stage  gates  and  portfolios, 
while  tailoring  these  ideas  to  their  needs  and  experiences.  Nevertheless,  the  literature  documents  its 
system  remains  plagued  with  many  issues  of  performance  in  terms  of  cost  and  schedule  of  its 
development  activities,  as  do  many  other  enterprises.  Finally,  the  literature  is  clear  that  construction  of 
a  model,  when  properly  done,  has  the  potential  to  shed  a  great  deal  of  insight  and  further 
understanding  on  the  behavior  of  systems  such  as  the  US  Air  Force's  acquisition  system. 
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CHAPTER  3  -  ACQUISITION 


The  Acquisition  piece  of  the  US  Air  Force  process  of  developing  new  systems  was  identified  early 
in  the  literature  search  as  having  a  great  deal  of  research  done  on  it.  However,  no  literature  had  been 
identified  about  the  application  of  the  ideas  of  risk  within  the  portfolios  of  development.  Furthermore, 
despite  the  existence  and  the  proliferation  of  risk  and  portfolio  methods,  improvements  in  PD  outcomes 
for  large,  complex  systems,  has  not  materialized.  To  find  evidence  about  PD  outcomes  and  to  better 
understand  portfolios  and  enterprise  risk,  an  exploratory  study  of  portfolio  leaders  was  undertaken  at 
one  of  the  US  Air  Force's  Product  Centers21.  The  design  of  the  study  rested  upon  the  analysis  of  semi- 
structured  interviews  of  these  aforementioned  leaders. 

From  an  analysis  of  the  literature,  an  ideal  portfolio  should  be  able  to  do  three  major  things 
guided  by  overall  strategy.  These  are  first,  maximize  return  on  investment  as  bound  by  capacity, 
secondly,  maximize  portfolio  throughput  or  minimize  the  age  of  the  money  tied  up  in  the  portfolio,  and 
thirdly,  minimize  cycle  time,  as  well  as  minimize  cycle  time  variability.  Likewise,  the  ideal  portfolio 
manager  should  have  true  gatekeeper  functionality,  where  they  can  start,  stop,  and  throttle  programs; 
exercise  control  over  the  requirements;  and  have  complete  control  of  resources.  These  capabilities  are 
"levers  of  control"  that  leaders  have  to  wield  influence  and  authority. 

As  noted  earlier,  portfolio  management  is  the  preferred  method  to  manage  product 

development  in  the  US  Air  Force  and  is  diffused  down  the  hierarchy  of  acquisition  leadership-through 

21  The  Air  Force  Product  Center  follows  a  classic  top-down  organizational  tree.  There  are  four  levels  in  the 
hierarchy.  The  lowest  level  (Level  III)  is  a  Squadron  commander  or  equivalent,  responsible  for  two  or  more 
programs  or  efforts.  The  next  level  (Level  II)  is  led  by  a  Group  commander  or  equivalent,  with  the  next  level  (Level 

I)  led  by  a  Wing  commander  or  equivalent.  The  top  level  (Level  0)  is  the  Center  commander.  This  particular  AFB 
has  5  Wings  or  equivalent  organizations  (Level  I).  Each  wing  contains  3  to  5  groups  or  similar  organizations  (Level 

II)  and  each  group  contains  2  to  6  Squadrons  or  similar  organizations  (Level  III).  The  respective  number  of  groups, 
and  squadrons,  etc.,  assigned  to  each  wing  is  dependent  upon  the  number  of  projects  being  managed.  A  Wing 
(Level  I)  consists  of  about  1200-1400  personnel  and  manages  more  than  2  dozen  major  programs  and  several 
dozen  minor  programs;  a  Group  (Level  II)  has  about  400-600  personnel;  and  a  Squadron  (Level  III)  has  100-200 
personnel,  and  so  forth. 
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wing,  group,  and  squadron  commanders.  It  was  hypothesized  that  understanding  the  capabilities  of 


portfolio  leaders  would  yield  the  most  valuable  and  interesting  information  about  acquisition  outcomes. 

The  questions  asked  during  these  interviews  were:  "What  is  the  current  'state  of  the  practice'  of 
portfolio  management  in  the  US  Air  Force?  How  is  risk  being  used  in  portfolio  management  activities  in 
the  US  Air  Force?  What  behaviors  or  constructs  can  be  observed  in  US  Air  Force  acquisition  that  might 
be  described  as  influenced  by  enterprise  risk?"  Other  questions  were  asked  about  decision-making, 
surprises,  dependencies  between  programs  and  other  topics.  Additional  questions  about  job 
responsibilities,  outcomes  and  performance  measures  were  asked  seeking  specificity.  Vague  responses 
were  met  with  follow-up  questions.  A  representative  sample  of  these  questions  can  be  found  in 
Appendix  B. 

The  format  was  an  open-ended,  semi-structured  interview.  Purposeful  sampling  was  used  in 
the  construction  of  the  interview  set.  This  method  was  chosen  since  "portfolio"  management  is  done  by 
a  limited  number  of  individuals  within  the  US  Air  Force.  Allowance  was  made  to  accommodate  and 
allow  snowball  sampling. 

Interviews  were  limited  to  organizations  that  physically  reside  at  the  Product  Center,  which  is 
the  acquisition  arm  (e.g.  product  development  center)  for  one  of  the  US  Air  Force's  product  portfolios. 
See  the  note  above  for  an  organizational  description.  24  of  45  Squadron  commanders  (Level  III  leaders), 
10  of  14  Group  commanders  (Level  II  leaders),  and  4  of  the  5  Wing  commanders  or  their  equivalent 
(Level  I  leaders)  are  located  at  the  Product  Center.  Therefore,  given  the  above  ground  rules  and 
constraints,  there  were  approximately  38  potential  interviewees  at  this  location.  A  total  of  18  people 
were  interviewed.  Some  interviews  contained  more  than  one  person.  The  sample  size  represents  11% 
of  all  squadrons,  36%  of  all  groups,  and  75%  of  the  wings  assigned  to  the  Product  Center,  or  21%  of  all 
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local  squadrons,  45%  of  all  local  groups,  and  75%  of  the  wings  physically  residing  at  the  Product 
Center22. 

Initial  Observations  and  Analysis 

Several  key  themes  emerged  from  the  interviews  that  cut  across  all  levels  of  the  hierarchy. 

These  themes  are  money,  personnel,  or  requirements,  or  some  combination  of  all  three  impacting  the 
outcome  measures  of  individual  programs,  resulting  in  increasing  costs  and/or  schedule  slips. 

Money  is  a  key  constraint  for  portfolio  leaders.  "Everything  is  really  about  the  purse  strings," 
opined  a  Group  commander  (Level  II  leader).  By  design,  the  government  has  placed  restrictions  upon 
the  ways  money  can  be  used  in  programs.  Most  of  these  deal  with  preventing  fraud  and  abuse.  Some 
deal  with  the  realities  of  fiscal  policy  and  monetary/treasury  realities.  Many  of  the  respondents  were 
frustrated  by  not  having  more  latitude  to  move  money  within  their  portfolio  as  needs  required,  or  to 
even  get  the  money  expeditiously  to  their  program  personnel.  "...  we  rely  on  a  lot  of  other  folks, 
particularly  your  MAJCOM,  your  air  staff  folks  to  get  the  money  to  come  down,"  said  a  Squadron 
commander  (Level  III  leader). 

Personnel  issues  came  up  in  two  different  dimensions.  Portfolio  leaders  complained  about  the 
lack  of  people  to  fill  key  positions  and/or  the  level  of  experience  of  existing  personnel.  "...  we  don't 
have  all  the  right  skill  sets  for  the  folks  that  are  trying  to  run  programs  now.  We  have  a  lot  of  vacancies, 
or  we  don't  have  the  right  skill  sets  in  programs,"  said  one  Squadron  commander  (Level  III  leader).  A 
Group  commander  said,  "It's  the  experience.  And  it  really  surprises  me  that  we  are  allowing  decisions  to 
be  made  or  [we  are]  making  decisions  based  upon  an  experience-base  that  is  not  really,  I  think, 

22  A  caveat  to  the  product  center's  representativeness  in  this  survey  is  that  it  is  responsible  for  the  development  of 
software-intensive  systems  &  very  limited  in  complex  hardware  development,  with  a  few  exceptions.  Some  of 
these  exceptions  were  included  in  the  initial  interview  pool  -  maintaining  a  wide  cross-section  of  PD  types  -  while 
also  providing  for  a  "reserve"  of  other  interviewees  with  the  same  kind  of  PD  breadth  for  a  later  date,  if  the  need 
arose. 
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adequate.  I've  got  sharp,  sharp  people  in  here.  Wonderful  people  but  then  I  take  a  look  and  they  don't 


have  the  experience." 

This  reality  forces  portfolio  leaders  to  constantly  evaluate  and  allocate  manpower  according  to 
need.  Said  one  Squadron  commander  (Level  III  leader),  "...  people  you  get  are  based  on  where  they 
think  the  priorities  are.  You  don't  necessarily  get  the  good  ones  if  they  don't  think  you're  priority  ..." 
Another  Squadron  commander  lamented,  "...  if  they  take  my  manpower,  because  then  ...  I'm  stuck,  I 
have  to  focus  on  only  my  highest  high-level  stuff,  my  high-priority  stuff." 

The  pressure  upon  personnel  resources  is  exacerbated  by  instability  among  user  priorities  and 
requirements.  Regarding  priorities,  a  Group  commander  (Level  II  leader)  shared  this  insight,  "  .  .  .the 
bottom  line  is  it  that  at  the  end  of  the  day  that  system  is  beholden  to  the  user  and  the  user  only  and  it's 
their  priorities  versus  the  priorities  of  the  enterprise  that  are  going  to  win."  Priorities  and  requirements 
are  often  intertwined  and  hard  to  distinguish.  A  thoughtful  Squadron  commander  (Level  III  leader) 
observed  the  following: 

"I  think  the  changing  user  and  I  won't  just  say  requirements,  because  they  don't  even  come  as 
requirements,  but  fancies:  'I  want  to  do  this  today.'  'I  think  that's  a  great  idea.'  Okay,  in  those 
great  ideas,  because  if  it  is  at  the  Pentagon  and  it  may  not  even  be  the  general  who  runs  it,  but 
his  staff,  when  they  have  great  ideas,  it  becomes  like,  you  know,  the  'birth.'  It's  . .  .  we're  gonna 
shortcut  everything  and  that's  probably  one  of  the  biggest  gripes  I  have,  I'll  tell  you.  We  get 
considerable  amount  of  re-taskings." 

Another  Squadron  commander  (Level  III  leader)  said:  "The  user  will  redirect  us,  so  we  do  get 
some  of  that,  more  time  stuff,  we'll  redirect  some  of  our  resources  to  do  stuff  like  that."  Finally,  the 
user  may  try  to  direct  things  more  than  they  should.  "There's  a  lot  of  folks  who  have  good  ideas  on  how 
to  solve  a  problem,  not  just  work  the  problem  which  needs  solved  and  they  tend  to  help  us  out  with 
solutions  as  well  as  requirements  and  that's  a  struggle  that  we  have  on  a  regular  basis,"  said  one  Group 
commander  (Level  II  leader). 

Within  the  portfolio  structure,  there  were  some  issues  that  depended  upon  the  level  a  leader 
occupied  in  the  hierarchy.  One  example  revolved  around  the  perceived  value  of  staff  personnel.  At 
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levels  closest  to  the  program  work,  there  was  doubt  expressed  about  the  value-added  of  these 
personnel.  At  higher  levels,  staffs  were  seen  as  a  "last  line  of  defense"  to  ensure  accuracy  of  program 
information  that  would  be  reviewed  at  higher  levels.  One  Squadron  commander  (Level  III  leader)  said: 
"Working  the  staff,  I  think,  is  the  hardest  part.  I  think  that  is  the  most  difficult  part.  The  commanders,  I 
think,  they're  pretty  good,  once  you  can  get  through  their  staff  and  get  on  their  calendars." 

Further,  at  higher  levels  of  responsibility,  commanders  felt  completely  empowered  to  do 
whatever  needed  to  be  done  to  ensure  portfolio  success.  Farther  down  the  hierarchy,  commanders  felt 
more  constrained.  Upon  closer  examination,  "completely  empowered"  might  be  too  optimistic.  All  of 
them  used  words  such  as  "influence,"  "shape,"  and  "work  with"  to  describe  their  portfolio  capabilities. 
This  was  particularly  true  for  high-visibility  programs,  ACAT  I  programs,  or  other  programs  under 
scrutiny  by  outside  parties. 

Another  noted  difference  among  the  hierarchy  was  that  the  farther  removed  leaders  were  from 
the  day-to-day  work  of  individual  programs,  the  more  time  they  spent  thinking  strategically.  The 
converse  was  true  for  Squadron  commanders  (Level  III  leaders).  "Flonestly  we're  focused  on  what  inch- 
stones  are  this  month,"  said  one  Squadron  commander. 

Another  topic  concerned  the  "value"  proposition  perceived  by  Squadron  commanders  (Level  III 
leaders)  and  program  personnel.  Non-essentials  seemed  to  be  over-emphasized  compared  to  program 
outcomes.  Lamented  one  Squadron  commander:  "The  fact  that  I  haven't  had  my  PHA  [a  health 
screening]  or  that  I  am  late  on  gas  mask  training  is  a  far  bigger  deal  up  the  chain  than  whether  or  not 
one  of  my  programs  slip."  Another  Squadron  commander  echoed  the  same  idea.  "...  there’s  so  much, 
it  seems,  not  associated  with  the  primary  acquisition  mission  that  seems  to  carry  a  high  level  of 
performance,  of  measure,  to  determine  your  success." 
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Finally,  these  individuals  were  reluctant  to  indicate  exactly  how  long  a  particular  task  or  activity 


in  the  acquisition  of  a  program  actually  took.  Oftentimes  their  responses  ranged  from  "it  depends,"  to  a 
very  rough  estimate.  When  pressed,  the  most  these  individuals  would  accede  to  was  a  range  of  time. 

Data  Coding  and  Analysis 

In  speculating  about  the  root  causes  for  these  issues,  it  is  clear  that  portfolio  management  and 
portfolio  risk  practices  (knowledge  of  and  use  of)  are  variable  and  not  standardized.  The  data  reveals 
limited  evidence  of  portfolio  behaviors  and  little,  if  any,  enterprise  risk  understanding. 

Further  analysis  of  the  interviews  was  done  through  a  coding  process,  wherein  92%  of  all  those 
interviewed  felt  Portfolio  Management  was  an  "art."  42%  acknowledged  having  no  portfolio-level  vision 
or  strategy  although  another  33%  claimed  to  have  a  vision  or  strategy.  33%  of  those  interviewed  want 
portfolio-level  measures,  while  acknowledging  difficulty  in  obtaining  such  measures. 

Portfolio  capabilities  were  explained  by  referring  to  individual  project  outcomes:  performance 
(requirements),  cost  (resources),  and  schedule  (time)  and  extrapolating  this  information  to  the  entire 
portfolio.  Therefore,  they  were  not  articulated  in  any  kind  of  formal  measures,  but  in  more  vague 
terms.  A  Squadron  commander  (Level  III  leader)  said:  "For  me,  it's  done,  it's  really  done  as 
'contentment'  among  the  portfolio  .  . .  and  if  I  have  that  good  feeling,  I'm  satisfied  with  the  direction  of 
the  entire  portfolio."  A  Group  commander  (Level  II  leader)  suggested,  "...  my  folks  really  don't  have 
the  ability  to  measure  against  their  goals,  other  than  saying  I've  got  that  vision  or  mission." 

Without  exception,  all  affirmed  the  use  of  risk  data  as  essential,  but  were  often  at  a  loss  to 
describe  exactly  how  it  was  used.  75%  of  those  interviewed  used  traditional  risk  tools,  e.g.  risk  cubes, 
mitigation  plans,  for  individual  programs.  50%  used  program-level  metrics  to  help  make  portfolio 
decisions  and  42%  used  "high-level"  reviews  to  discuss  risks  of  multiple  projects-but  without  a 
structured  process  or  integration  of  risks  between  projects.  Most  felt  that  these  reviews  were  adequate 
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in  vetting  the  highest-level  risks  among  programs,  but  that  it  was  not  overall  very  efficient,  e.g.  time¬ 


consuming. 

The  concept  of  portfolio  risk  was  challenging  for  many.  Almost  all  interviewed  had  a  different 
definition  and  understanding  of  portfolio  risk  and  what  it  meant  for  them.  Only  25%  of  those 
interviewed  claimed  to  have  a  set  of  portfolio  risks  and  one  leader  had  an  integrating  contractor 
managing  those  risks23.  42%  said  limited  manpower  prevented  the  use  of  portfolio  risk  management 
and  33%  felt  that  the  structure  of  their  organization  inhibited  portfolio  risk  management. 

Further  Discussion 

Portfolio  objectives  within  the  Acquisition  community  of  the  US  Air  Force  seem  to  be  somewhat 
at  odds  with  traditional  portfolios.  While  it  is  true  that  portfolios  serve  as  a  categorization  method, 
many  of  the  current  pairings  of  program  to  portfolio  do  not  make  sense.  They  often  seem  to  have  been 
made  due  to  geographic  proximity  or  budgeting  categorization,  not  necessarily  regarding  a  shared 
system  commonality,  a  strategic  vision  or  other  typical  portfolio  objectives.  While  portfolio  leaders  are 
expected  to  live  within  the  resources  available,  they  have  little  ability  to  adjust  resources  accordingly. 
Further,  portfolios  are  also  used  as  a  reporting  vehicle  where  good  news  is  spread  quickly  and  widely 
and  bad  news  is  often  kept  "in  house"  as  long  as  possible.  Finally,  emphasis  is  placed  upon  portfolio 
leaders  to  mentor  the  program  managers  in  the  art  of  program  management.  These  are  not  necessarily 
bad  things,  but  are  also  not  representative  of  traditional  portfolio  management  constructs. 

In  this  environment,  systemic  constraints  and  organizational  constructs  doom  the  leader  to 
mediocre  portfolio  performance.  They  have  few  effective  levers  of  control  to  influence  portfolio 
performance.  They  have  little  capability  to  prune  the  portfolio  or  to  "throttle"  the  execution  of  existing 

23  The  contractor  was  also  interviewed.  Although  they  had  accepted  the  task  of  managing  portfolio  risks, 
determining  those  risks  was  proving  to  be  very  difficult  &  at  the  time  of  the  interview,  and  after  several  months  of 
effort,  they  did  not  yet  have  any  portfolio  risks  enumerated. 
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programs,  e.g.  speed  up,  slow  down.  These  controls  are  exercised  elsewhere  in  the  US  Air  Force. 
Although  they  may  serve  in  gatekeeper  functions  with  a  great  deal  of  responsibility--as  a  Source 
Selection  Authority,  Milestone  Decision  Authority,  or  to  function  as  an  Award  Fee  Designating  Official, 
portfolio  managers  are  limited.  As  a  program  advocate,  portfolio  leaders  become  reputation  managers, 
lobbyists,  and  information  conduits.  Perhaps  their  greatest  area  of  influence  exists  at  the  start  of  new 
programs  because  they  carve  out  the  initial  team  of  personnel  and  resources  until  the  official  processes 
"catch  up"  with  the  new  program.  Perhaps  the  only  lever  of  control  totally  within  their  purview  is  the 
contractual  mechanism  with  industry.  However,  even  this  lever  is  constrained  by  financial  pressures 
outside  the  control  of  the  portfolio  leader. 


Resource 
Flexibility 
(none  to  full) 


(none  to  full) 


Figure  18:  Portfolio  Manager  Capability  Matrix 

Based  on  the  analysis  of  the  interviewees  from  the  US  Air  Force  Acquisition  system,  Air  Force 
"portfolio  managers"  lie  squarely  within  quadrant  three  of  the  above  diagram-severely  constrained  and 
largely  ineffective  in  managing  their  portfolios. 
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The  consequences  of  constrained  portfolio  managers  become  clearer.  Rather  than  occupying 


the  upper  left  quadrant,  characterized  by  fully  staffing  uncertain  projects  (seed  corn),  keeping  the 
number  of  projects  low,  and  maintaining  overcapacity  in  processes,  money,  and  people,  the  Air  Force 
does  the  opposite.  Rather  than  occupying  the  upper  right  quadrant,  characterized  by  minimizing 
projects  in  the  pipeline,  focused  portfolio  reviews  and  keeping  a  focus  on  project  schedule,  the  Air  Force 
exercises  little  discipline  in  these  areas.  Instead,  chaos  and  firefighting24  [119]  in  the  development  of 
systems  is  the  result. 

Observed  outcomes  are  also  different  than  what  might  be  expected  from  a  portfolio 
management  process.  Cost,  schedule  and  performance  data  for  programs-and  by  extension,  portfolios- 
exhibit  huge  instabilities,  trending  in  undesired  directions.  Mismatches  in  strategy  between  programs 
and  the  portfolio  are  common.  For  instance,  portfolio  vision  and  focus  can  be  diluted  due  to  the 
cacophony  of  stakeholder  voices  and  system  inputs  at  all  levels.  Using  the  McDonough  and  Spital  [89] 
framework  to  evaluate  portfolio  performance,  the  US  Air  Force  seems  intent  on  "Operationalizing"  all  of 
the  projects,  e.g.  all  projects  are  developed  and  fielded,  within  its  portfolio  rather  than  adhering  to  a 
defined  portfolio  strategy,  e.g.  careful  selection  and  pruning  of  projects  in  the  portfolio,  as  well  as  not 
providing  the  tools,  e.g.  the  levers  of  control,  necessary  to  ensure  portfolio  success.  The  following  figure 
illustrates  the  quadrant  of  activity  where  the  US  Air  Force  resides. 


Firefighting  in  product  development  is  a  term  coined  to  describe  the  behavior  of  diverting  important  resources 
to  solve  unanticipated  problems;  being  reactive  in  the  development  of  a  new  product  versus  being  pro-active. 
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Figure  19:  Portfolio  Domain  Space 

Another  dominant  observation  from  these  interviews  is  that  portfolio  leaders  recognize 
everyone  is  working  very  hard.  It  would  be  easy  for  them  to  "blame"  personnel  for  most  of  the  cost, 
schedule  and  performance  issues,  but  they  do  not.  They  recognize  people  generally  have  the  best  of 
intentions  and  their  actions  are  often  focused  by  the  system  towards  local  optima  versus  global  ones. 

Overall,  the  emergent  themes  are  not  especially  surprising.  They  reveal  resources,  such  as 
people,  money,  and  requirements  contribute  to  poor  portfolio  outcomes.  In  terms  of  "people,"  there  is 
a  concern  there  are  not  enough  of  them  to  do  the  job  or  they  do  not  have  the  proper  skill  set. 

Regarding  "money,"  it  is  highly  constrained  and  bound  by  rules  that  are  cumbersome.  Finally, 
requirements  are  fluid,  ranging  from  shifting  priorities  to  re-taskings  to  preferred  solutions.  The 
consequences  of  these  issues  manifest  themselves  through  schedule  and  cost  growth.  However,  they 
are  not  necessarily  the  root  cause.  These  themes  reflect  a  system  that  is  constantly  in  a  fire-fighting 
mode,  trying  to  keep  every  project  going  despite  an  apparent  lack  of  system  capacity  required  to 
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proceed.  The  result  is  programs  that  are  constantly  under  financial  and  organizational  pressures  to  do 


"more  with  less."  Schedules  slip  and  programs  overrun  their  budgets. 

Risk  management  practices  observed  are  used  at  the  project  level  with  unsatisfying  attempts  to 
reconcile  them  to  the  portfolio  level  because  it  is  hard  to  compare  risks  between  projects.  Current 
methods  used  appear  to  be  very  simplistic  and  not  as  robust  as  methods  advocated  by  the  literature  or 
are  in  place  "on  paper"  only. 

Potential  measures  for  further  research 

Clearly,  enterprise  risks  are  not  easily  articulated.  However,  several  potential  candidates  can  be 
postulated  as  enterprise  or  portfolio  risks.  Using  the  Stanke  framework  as  a  starting  point,  measures  for 
agility,  flexibility  and  alignment  could  be  proposed  [93],  What  are  potential  portfolio  measures  for 
agility?  Perhaps  acquisition  process  capacity,  borrowing  concepts  from  queuing  theory,  and  process 
capability,  skills  and  depth  of  personnel,  might  be  good  surrogate  measures.  Flexibility?  A  measure  of  a 
"portfolio  reserve"  vs.  total  budgeted  baseline,  the  percent  of  unused  process  capacity,  and  a  portfolio 
leader's  social  network  measures,  such  as  centrality,  might  be  good  ways  to  measure  it.  Alignment?  A 
subjective  "measure"  of  all  programs  in  the  portfolio  to  the  overall  strategy  or  measuring  the  strategic 
priority  of  the  programs  in  the  portfolio  might  work  for  alignment.  Much  more  work  is  required  to  fully 
develop  these  ideas  further  and  is  outside  of  the  scope  of  this  dissertation. 

The  bottom  line  is  that  measures  such  as  these  do  not  currently  exist.  Many  of  the  data 
required  to  develop  such  measures  are  not  even  collected  or  are  closely  guarded.  For  instance,  not  one 
portfolio  leader  would  divulge  his  estimated  manpower  requirements  or  his  actual  personnel  numbers- 
only  verbal  acknowledgement  that  their  manning  was  somewhere  between  70%  and  90%  of  what  was 
"on  the  books."  Overcoming  obstacles  like  this  will  be  critical  in  developing  enterprise  risk  measures. 
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Conclusions 

The  "state  of  the  practice"  of  product  portfolio  management  in  the  US  Air  Force  is  poor 
compared  to  organizations  recognized  as  implementing  best  practices.  The  design  and  execution  of  the 
current  acquisition  system  is  pre-disposed  against  portfolio  leaders  implementing  portfolio  best 
practices.  Practices  that  imply  enterprise  risk  management  and  portfolio  management  are  used 
heuristically,  at  best.  More  often,  where  some  of  these  practices  are  employed,  they  are  used  in  a 
disjointed  and  disconnected  manner  by  lower  level  portfolio  leaders  that  remain  aloof  from  the  overall 
portfolio.  In  many  instances,  it  is  impossible  to  identify  which  "uber-portfolio"  a  system  should  belong 
to  as  many  "portfolios"  claim  a  system  as  an  integral  part  of  the  larger  portfolio.  Enterprise  measures 
are  not  in  place.  "Current-state  assessment"  of  process  capacity  is  not  available;  personnel  and  other 
resource  shortages  lie  outside  of  the  control  of  the  portfolio  leader.  Outcome  measures  for  the 
portfolio  are  based  solely  on  individual  project  outcomes--not  necessarily  an  "optimal"  approach  to 
portfolio  management.  It  is  very  difficult  for  portfolio  leaders  to  refuse  taking  on  additional 
requirements.  Portfolio  objectives  seem  to  be  focused  on  being  a  vehicle  to  report  on  and  categorize 
different  projects  or  programs.  Finally,  in  an  apparent  effort  to  mitigate  some  of  the  shortcomings  of 
the  existing  acquisition  system,  portfolio  leaders  have  been  pushed  out  into  the  "field,"  in  order  to  be 
"closer"  to  those  programs  to  enable  mentoring  of  leadership  personnel. 

Nevertheless,  critical  thinking  about  enterprise  risk  is  in  a  nascent  stage  within  the  US  Air  Force. 
Potential  enterprise  risk  measures  are  not  meaningful  in  their  present  form  but  have  emerged  as  viable 
candidates  for  future  study  and  hypotheses  testing.  Furthermore,  this  short  study  also  suggests  that 
most  of  the  poor  outcomes  of  the  acquisition  system  can  be  attributed  to  factors  elsewhere,  outside  of 
the  boundaries  of  the  system.  Many  of  the  pathologies  plaguing  program  managers  lie  outside  of  their 
control.  A  larger  systems  approach  is  required  to  cover  all  of  the  causal  factors  of  Acquisition  outcomes. 
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Despite  this  bleak  sounding  assessment,  acquisition  still  seems  to  do  remarkably  well  given  the 


constraints  it  operates  under.  Systems  are  being  designed  and  developed  to  meet  war  fighter  needs, 
even  if  the  system  tends  to  favor  performance  versus  any  other  outcome  measure.  Whether  these 
outcomes  are  a  function  of  the  capability  of  the  personnel  working  in  the  acquisition  system  or  sheer 
luck  is  more  likely  a  testament  to  the  dedicated  people  working  in  this  system. 


82 


CHAPTER  4  -  THE  OTHER  PARTS  OF  THE  ACQUISITION 
SYSTEM 

Reflecting  upon  the  major  takeaways  of  the  study  of  acquisition,  including  that  many  of  the 
causal  factors  of  the  outcomes  of  acquisition  originated  outside  of  acquisition,  it  was  doubly  important 
to  characterize  and  understand  the  other  elements  of  the  acquisition  system.  This  chapter  focuses  on 
those  two  other  parts,  the  financial  system  or  the  Programming,  Planning,  Budgeting  and  Execution 
(PPBE)  process  and  the  requirements  generation  system,  otherwise  known  as  the  Joint  Capability 
Integration  Development  System  (JCIDS). 

By  taking  the  time  to  critically  examine  these  two  systems  and  characterize  them,  it  was 
hypothesized  that  evidence  of  root  causes  of  acquisition  problems  could  be  found  by  interviewing 
people  working  within  these  two  systems.  Perhaps  the  acquisition  process  discussed  in  Chapter  3  really 
was  doing  "well"  given  the  constraints  that  it  operated  under.  Therefore,  a  study,  similar  to  the  one 
discussed  in  Chapter  3,  was  organized  to  determine  how  these  systems  really  operate  and  characterize 
them  with  an  added  emphasis  upon  the  outcome  measures  of  cost  and  schedule  and  the  influence  or 
impact  that  these  two  processes  exert  upon  the  other  acquisition  system. 

The  initial  step  was  to  scope  the  study  and  determine  the  pool  of  interview  subjects.  Pool 
selection  began  with  a  thorough  search  of  the  internal  Air  Force  directory  system.  The  first  criterion  for 
selection  was  that  an  interviewee's  organization  needed  to  participate  directly  in  one  of  the  two 
systems  in  question,  JCIDS  or  PPBE.  The  second  criterion  was  to  gain  a  cross-section  of  people  both  at  a 
major  command,  as  well  as  others  within  headquarters  Air  Force,  so  the  system  could  be  understood 
from  beginning  to  end.  Organizations  and  individuals  that  participated  in  previous  work  were  also 
considered  [109],  The  final  selection  was  accomplished  by  examining  duty  titles,  and  then  contacting 
previous  contacts  or  placing  cold-call  telephone  calls  and  sending  e-mails  requesting  availability  and 
interest  in  participating.  The  format  was  an  open-ended,  semi-structured  interview.  Allowance  was 
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made  to  accommodate  and  allow  snowball  sampling;  thereby  increasing  the  size  of  the  sample  pool,  and 


taking  advantage  of  additional  networks  of  people  in  other  organizations.  The  snowball  sampling  was 
actually  quite  effective  as  it  led  to  several  other  interviews. 

Examples  of  some  of  the  possible  questions  asked  during  these  interviews  were:  "What  is  the 
role  of  your  organization  with  respect  to  the  system  that  you  are  a  part  of?  Given  a  specific  task,  how 
long  does  it  usually  take  to  accomplish  that  task?  Where  does  your  organization  and  your  job  fit  into  the 
PPBE  or  JCIDS?  How  do  you  interact  with  the  other  pieces  of  the  acquisition  system?  What  is  the 
current  'state  of  the  practice'  of  portfolio  management  in  the  US  Air  Force?  How  is  risk  being  used  in 
portfolio  management  activities  in  the  US  Air  Force?  What  behaviors  or  constructs  can  be  observed  in 
US  Air  Force  acquisition  that  might  be  described  as  influenced  by  enterprise  risk?"  Interviewees  were 
encouraged  to  walk  a  program  through  the  PPBE  and  JCIDS  from  their  perspective,  the  time  required  to 
complete  each  step  or  task  in  the  process,  and  any  vagaries  that  they  were  especially  aware  of  that 
others  might  not  be.  More  questions  were  asked  about  decision-making,  surprises,  and  dependencies 
between  programs,  among  other  topics.  Additional  questions  about  job  responsibilities,  outcomes  and 
performance  measures  were  asked  to  add  specificity  if  it  helped  with  the  context  of  other  answers. 
Vague  responses  were  met  with  follow-up  questions.  A  larger  sample  set  of  representative  questions 
appears  in  Appendix  C. 

The  organizations  that  participated  include  elements  of  a  major  command,  portions  of  the  Air 
Force  Secretariat  staff  and  other  parts  of  the  Air  Staff.  More  specifically,  individuals  from  the 
Secretariat's  Office  of  Acquisition  Policy,  the  Air  Staff  A3  (Operations)  and  A5  (Plans  and  Requirements), 
a  major  command's  JCIDS  policy  and  resources  division,  and  few  representatives  of  the  user  community 
(JFCOM  -  Joint  Forces  Command,  GCIC  -  Global  Cyberspace  Integration  Center),  giving  both  a  joint  and 
Air  Force-centric  user  perspective.  In  all,  more  than  25  different  professionals  were  interviewed. 
Specifically,  five  of  these  interviews  came  from  the  requirements  community,  another  seven  interviews 
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represented  the  user  community,  and  more  than  thirteen  interviews  represented  the  PPBE  community. 


In  each  of  these  different  groups,  representatives  from  the  earliest  phases  of  the  process  up  through  the 
hierarchy  to  Headquarters  Air  Force  were  interviewed.  The  skew  towards  the  PPBE  is  deliberate- 
previous  work  mentioned  earlier  did  not  include  expertise  in  this  area. 

Results  and  Analysis 

The  results  of  these  interviews  are  helpful  and  enlightening  in  more  fully  characterizing  these 
two  systems.  In  the  next  few  pages,  a  closer  and  candid  look  into  the  operations  of  the  different 
processes  of  JCIDS  and  PPBE  will  be  given.  The  JCIDS  process  is  interesting  for  the  reason  that  it  is  event 
driven  and  it  tends  to  stick  closely  in  form  to  the  process  that  has  been  laid  out  by  regulation.  It  is  not  a 
process,  however,  to  be  strictly  defined  by  exact  timelines  or  time  limits  assigned  to  a  particular  task 
activity.  There  is  a  great  deal  of  variability  in  the  way  that  the  system  behaves  over  time-some  items 
can  sail  through  the  process,  and  others  take  an  extraordinary  amount  of  time.  The  PPBE,  on  the  other 
hand,  operates  most  closely  according  to  its  published  timeline  found  in  the  literature.  Part  of  this  is  an 
artifact  that  it  has  a  set  deliverable  due  every  year  at  the  same  time  for  congressional  submission  and 
subsequent  debate. 

The  key  issues  and  themes  identified  during  the  study  will  be  broken  out  into  separate  sections 
to  aid  in  better  understanding  these  parts  of  the  overall  system. 

The  Program  Element  Monitor 

One  personnel  position  emerged  as  having  a  critical  role  in  the  larger  process  or  the  "big  A"  of 
acquisition.  A  majority  of  the  interviewees  mentioned  this  person  unprompted  in  the  course  of  their 
responses.  This  position  is  the  Program  Element  Monitor  or  PEM.  The  name  PEM  comes  from  the 
budgeting  artifact  of  a  Program  Element  or  a  PE.  A  PE  is  how  the  Air  Force  describes  the  activity  to 
Congress  and  how  much  will  be  spent  in  a  particular  area.  This  makes  a  PEM  responsible  for  many  of 
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the  financial  issues  a  program  deals  with.  Sometimes  a  PEM  is  responsible  for  just  one  PE-other  PEMs 


may  have  responsibilities  for  as  many  as  10  at  a  time.  Furthermore,  there  are  PEMs  in  many  different 
locations-within  the  little  "a"  of  acquisition,  e.g.  at  the  SAF/AQ  level,  major  commands,  and  also  within 
some  of  the  A-Staffs  at  the  Headquarters  Air  Force,  as  mentioned  earlier.  The  following  table  highlights 
some  of  the  concerns  raised  by  or  about  the  PEM. 


Possible  Root  Cause  or  Causal  Mechanism 

Emergent  Behavior  or  Effect  on  System 

Span  of  control  required 

Some  PEMs  have  too  much;  others  not  enough 
-programs  can  be  at  risk  of  losing  resources 
because  they  can  not  be  properly  defended 
during  tough  questioning  because  PEM 

doesn't  have  time  to  know  all  of  the  issues 

Trust  issues  between  acquisition  organizations 
(program  offices  and  secretariat  staffs)  and 

PPBE  officials 

-Information  hoarding;  Resource  preservation 
becomes  motivating  factor;  bad  news  is 
delayed  as  often  as  possible,  perhaps  holding 
out  hope  for  better  news  or  a  miracle 

Budget  drills  and  changing  spending  plans 

Constant  churn  in  funding  plans;  schedules, 
total  program  resources;  can't  focus  on 
program  strategically-always  reactionary 

Table  4:  Issues  specific  for  Program  Element  Monitors  (PEMs) 


"The  PEM  is  where  the  acquisition  chain  and  PPBE  chain  come  together"  was  a  common  theme 
among  interviewees.  Others  declared  that  the  PEM  should  work  capability  issues  across  PEO  portfolios, 
but  sometimes  it  is  not  happening. 

Other  representative  quotes  include: 

"On  some  of  the  smaller  programs,  a  lot  of  PEMs  who  work  more  programs  will  have 
five  or  six  of  them  [PEs] 25  that  they're  worried  about,  so  they  don't  [can't]  necessarily 
keep  track  of  them  every  day."  (PEM  Supervisor) 


PE:  Program  Element.  A  PE  is  the  accounting  mechanism  used  to  track  funding  for  a  particular  project  or 
weapon  system  or  acquisition  effort. 
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"It  can  be  kind  of  frustrating  to  you  when  your  program  office  finally  pops  up  and  comes 
clean  with  something  that  they  may  have  known  about  for  a  couple  of  months  or 
longer."  (From  a  frustrated  PEM  interview) 

"And  so  they  go  through  a  lot  of  budget  drills  trying  to  figure  out  where  they  might  be 
able  to  take  offsets  to  fund  other  things.  Well,  some  of  those  can  come  from  out  of  the 
blue  also  and  so  you  have  to,  you  know,  somebody  comes  up  with  what  looks  like  a 
pretty  harebrained  idea  to  try  to  cut  your  program  and  save  some  money  and  redirect  it 
elsewhere,  and  you  have  to  pretty  quickly  try  to  figure  out  where  the  impact  is  to  the 
program  and  get  that  back  into  the  corporate  structure  so  the  best  decision  can  be 
made.  That's  probably  the  biggest  churn  items  that  you  get."  (From  a  supervisor  of 
PEMs) 

A  PEM's  working  time  horizon  is  usually  short-term  in  nature  but  requires  an  understanding  and 
context  working  within  the  system: 


"I'd  say  that  there's  a  bit  of  a  range,  but  I'd  say  most  issues, ...  I'd  say  probably  fully  a 
third  of  the  time  you're  working  fairly  short-term  issues,  probably  less  than  a  weeks 
duration  you  get.  .  .  .  Very  rarely  are  you  dealing  with  things  that  have  a  horizon  of 
several  months.  Like  if  you  have  a  milestone  coming  up  that  probably  involves  a  limited 
amount  of  effort  spanning  a  couple  of  months."  (PEM  supervisor) 

"A  good  PEM  will  know  what  time  of  the  year  is  good  to  ask  for  additional  funding,  like  if 
you're  coming  into  the  spring  execution  review  or  just  after,  they'll  have  a  sense  for  that 
and  know  that  that's  a  good  time  to  try  to  make  those  trades,  or  right  at  the  end  of  the 
year  as  some  money  might  be  expiring."  (PEM  supervisor) 

"Depending  on  the  path  you  take,  it  would  be  within  a  week,  or  in  many  cases  the 
horizon  for  something  like  that  is  maybe  as  long  as  a  month.  ...  If  you  find  out  about  it 
in  November,  you  may  be  forced  to  kind  of  cool  your  heels  and  wait  for  an  opportunity 
which  may  not  come  until  spring  execution  review  four  months  later."  (From  a  PEM 
supervisor  asked  about  moving  money) 
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Despite  the  accountability  function  they  provide,  a  PEM  still  doesn't  have  full  control 


over  the  money  they  manage.  A  PEM  supervisor  remarked,  "PEM’s  know  the  financial  status  of 
the  program,  but  can't  move  the  money.  Only  a  resource  manager26  can." 

The  PEM  seems  to  have  a  critical  role  in  the  workings  of  the  Big  "A"  of  Acquisition,  but, 
based  upon  the  comments  and  observations,  suffers  from  the  same  kinds  of  drawbacks  that 
"Portfolio  Managers"  in  the  Air  Force  do,  in  that  they  are  constrained  in  a  similar  fashion. 


Other  Identified  Issues 

Over  30  different  items  for  further  analysis  were  identified  through  the  interviews  and 
these  were  distilled  down  to  11  overarching  issues.  Four  of  these  issues  were  identified  in  both 
the  PPBE  and  JCIDS  interviews  and  one  issue  came  from  JCIDS  and  the  user  communities. 
Oftentimes,  a  potential  solution  was  proffered  by  the  same  interviewee.  The  following  tables 
illustrate  these  issues  along  with  supporting  quotes. 


Possible  Root  Cause  or  Causal  Mechanism 

Emergent  Behavior  or  Effect  on  System 

No  systemic  approach  to  check  context  or 
interdependencies/duplication  between 

programs 

Priorities  in  flux;  Program  turbulence  as 
decisions  are  made  without  regard  to 
interdependencies;  some  duplication  of  efforts 

Decision  avoidance;  Major  decisions  are 
constantly  being  revisited 

Program  turbulence;  changing  priorities  and 

directions 

Requirements  change;  Requirements  creep; 
scope  changes 

Churn  in  program  forecasts;  budget 
requirements;  schedules;  estimates  to 
completion 

26  The  resource  manager  referred  to  can  be  either  another  PEM  that  manages  execution  year  money  (such  as 
those  in  SAF/AQX)  or  someone  in  the  AF  Comptroller's  office  or  working  in  the  Financial  Management  (FM) 
functions.  In  many  cases,  the  type  of  resource  manager  is  determined  by  the  kind  of  financial  money  movement 
anticipated  (changing  colors,  working  a  swap  or  trade  with  another  PEM,  etc.)  or  the  amount  (crossing  a  threshold) 
involved. 
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Process  for  resource  allocation  is  conflict- 
oriented;  consensus-building;  qualitative 


No  formalized  process  to  systematically 
discover  and  react  to  interdependencies; 
priorities  in  flux  and  change  according  to 
personalities  in  corporate  process 


Table  5:  Common  issues  identified  by  individuals  in  JCIDS  and  PPBE 


Interdependencies 

Many  interviewees  declared  that  there's  no  formal  process  to  discover  or  track  program 
redundancies.  Some  were  looking  for  an  interdependency  table  or  an  interdependency  understanding 
between  programs.  According  to  those  interviewed,  interdependencies  between  programs  are  hard  to 
do;  it's  done  manually;  there  is  no  strength  of  relationship  between  the  programs  assigned.  Some 
interviewees  maintained  the  process  dealt  with  dependencies  between  other  programs.  As  a 
dependency  is  " .  . .  Articulated  within  the  panel,  [if]  they  have  a  related  program  and  then  as  it  moves 
up,  beginning  at  the  group  level  and  higher,  we  look  at  everything  together."  Ironically,  there  is  a  tool27 
that  the  Air  Force  owns  where  one  of  its  purposes  is  to  show  interdependencies,  but  it's  not  being  used 
for  that.  "Most  other  organizations  have  their  own  databases,"  according  to  the  tool's  manager.  Some 
suggested  that  better  training  for  managing  interdependencies  between  programs  would  correct  many 
process  deficiencies. 

The  following  quote  is  a  great  example  of  the  way  the  PPBE  treats  every  requirement 
independent  of  all  others: 

"Each  JCIDS  document  goes  through  the  system  by  itself.  If  I  approve  the  requirements  for  this 
program  and  decide  that’s  where  I'm  going  to  put  my  dollars,  that's  what  I'm  going  to  pursue. 
Better  idea  comes  up  next  week?  Well,  I'd  like  to  do  that,  but  I  already  spent  my  money  over 
here.  So  from  a  requirements  perspective,  as  those  documents  go  through,  there's  no  context 
related  that  I  can  understand  those  types  of  relationships.  In  theory  EVMS  is  supposed  to 
provide  that,  but  I  just  haven't  seen  it."  (PPBE  participant) 


IRSS:  an  integrated  requirements  database  that  is  designed  to  help  facilitate  the  approval  process  of  AF 
documents  in  the  JCIDS  process.  A  documented  feature  is  the  ability  to  identify  interdependencies  with  other 
programs. 


89 


Decision  Making 

When  it  comes  to  making  hard  decisions,  a  JCIDS  participant  had  the  following  observation: 

"I  think  in  some  cases,  there's  not  the  will,  the  decisiveness  of  somebody  at  the  appropriate 
level  to  say  'No,  this  is  a  bad  idea.'  You  usually  don't  see  that  on  the  requirement  side.  I  think 
budgeting  and  POM  type  decision-making  is  where  more  initiatives  get  killed  than  on  the 
requirement  side.  .  .  .  We  can  write  CCDs  all  day  long,  but  if  the  POM  process  doesn't  support  it, 
it  ain't  going  to  happen;  if  AT&L28  is  not  willing  to  approve  a  program,  it's  not  going  to  happen. 
So  I  think  . . .  perhaps  we  have  the  leverage  on  stopping  something.  Maybe  that's  where  all 
three  of  those,  budget,  acquisition,  requirements  may  be,  [but]  they've  got  more  power  to  stop 
something  than  they  do  to  make  it  happen.  Or  maybe  not."  (JCIDS  process  policy  interviewee) 

Mass  coordination  can  be  a  way  to  avoid  making  decisions: 

"We  waste  a  lot  of  time  sending  things  out  for  marginal  improvements  via  mass  coordination 
versus  saying  you  are  the  expert.  You  have  the  authority  to  manage  that  function  (without  Air 
Force  coordination).  We  make  everything  everyone  else's  business.  I  think  that  is  our  biggest 
bottleneck  —  the  way,  we  need  to  get  everyone's  permission  —  on  pretty  much  anything...  for 
fear  of  leaving  somebody  out  of  the  loop,  we  send  it  out  to  everybody."  (JCIDS  participant) 

Requirements  Change 

Many  interviewees  opined  that  the  biggest  source  of  instability  is  requirements  change.  The 
following  quote  is  illustrative  of  the  interaction  between  the  various  systems  of  acquisition  when 
requirements  change: 

". .  .  We  in  A529  generate  the  requirement.  Once  that  requirement  gets  approved  and  it  goes 
into  the  acquisition  community  and  they  work  with  the  SPOs30  and  AFMC31  finalizing  the  pricing- 
-there's  a  whole  group  of  people  that  do  cost  estimates.  .  .  .  Now  the  program  world,  the  link  is, 
we've  got  to  understand  what  the  requirement  is,  we've  got  to  understand  about  how  much  it 
costs  because  we  have  yet  to  get  the  money  lined  up  about  two  years  before  the  contract  was 
let32.  So,  that  creates  a  lot  of  churn,  you  know, ...  so  that  causes  ripples  in  the  programmatic 
world.  But  they're  all  linked  at  the  hip."  (PPBE  participant) 

28  AT&L  refers  to  the  Department  of  Defense  level  office  of  Acquisition,  Technology  and  Logistics,  residing  in  the 
Undersecretary  of  Defense  for  Acquisition's  office 

29  A5:  A  Headquarters  AF  organization.  This  particular  organization  has  generated  requirements  for  a  mission  that 
doesn't  yet  have  a  Major  Command  sponsoring  work  in  this  area.  When  a  Major  Command  assumes  this  mission, 
A5  will  revert  to  a  more  traditional  role  at  the  Headquarters. 

30  SPO:  System  Program  Office 

31  AFMC:  Air  Force  Materiel  Command  -  Major  Command  responsible  for  the  majority  of  AF  Acquisition  efforts 

32  Two  years  refers  to  the  amount  of  time  required  to  navigate  the  PPBE  from  start  to  finish 
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Within  the  PPBE  regarding  a  change  to  the  requirements: 


"There's  a  lot  of  socializing,  consensus  building,  you  know,  a  lot  of  political  type  overtones  and 
things  like  that  where  you  have  to  work  with  a  lot  of  people,  and  you'd  better  not,  sort  of,  and 
knock  over  their  rice  bowls.  You  have  to  bring  everyone  together  and  sort  of  get  people  to  work 
as  a  team,  brief  leadership.  After  you  get  consensus  at  the  action  officer  level,  you  brief 
leadership  and  tell  them  this  is  what  we're  going  to  gain  by  doing  this.  And  then  you  have  to 
execute.  Then  you  have  to  adjust  the  schedules  and  update  the  documents,  and  update  the 
PEM  parades33  and  update  everything  that  you're  going  to  be  briefing  up  to  the  IT  exhibit  and 
the  roadmaps."  (PPBE  participant) 

According  to  interviewees,  this  takes  anywhere  from  a  week  to  up  to  a  year,  but  the  time  to 
shut  down  and  kill  a  program  can  take  about  a  month  or  longer,  "...  and  the  decision  to  kill  something 
still  keeps  getting  revisited"  (PPBE  participant). 

Conflict-oriented;  qualitative;  consensus-building 

The  corporate  process  in  the  Air  Force  ultimately  sets  priorities  by  allocating  resources  for  those 

activities.  However,  one  concerned  PPBE  participant  remarked: 

"I  know  that  in  the  POM,  just  like  we  did  in  APOM,  we  prioritize  and  we  talk  about 
radioactivity34.  They  have  two  scales  you  prioritize  one  through  N  and  you  prioritize  A  through 
D,  one  of  them  being  external  to  the  Air  Force?  Is  it  high-level  push  versus  local?  Another  one 
is,  is  it  "A"  radioactive,  meaning  that  there  is  high-level  politics,  versus  "D,"  low-level.  I  have  not 
seen  any  type  of  quantitative  analysis  that  would  be  used  to  be  able  to  explain  why  you  placed  a 
capability  or  program  in  a  certain  bucket." 

Another  user  remarked,  "Do  you  control  the  money,  or  are  you  just  influencing  it?  And  I  think 
we  saw  through  our  experiences  here  that  without  control  of  it  the  influence  doesn't  go  a  long  way, 
necessarily." 


"PEM  parade"  is  a  term  used  to  describe  the  series  of  meetings  lasting  several  days  where  PEMs  are  "paraded" 
before  the  leadership  of  the  organization  to  brief  and  defend  their  programs  from  a  financial  perspective.  This 
activity  is  usually  near  the  beginning  of  the  PPBE  cycle. 

34  A  term  used  in  the  PPBE  corporate  process  to  assess  the  politics  associated  with  a  program. 
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'The  whole  corporate  structure,  this  is  my  opinion,  you  know,  it's  designed  to  be  conflict 


oriented,  just  like,  kind  of  like  the  government,  in  the  sense  that  it  depends  on  conflict  between  these 
major  organizations,  A8,  A5,  AQ."  (PPBE  participant) 

Here  is  another  perspective  from  a  JCIDS  participant: 

"AQ  kind  of  brings  to  the  table  all  the  acquisition  expertise.  A5  kind  of  works  all  requirements.  . 
. .  A8  is  more  or  less  the  budgeters.  The  guys  in  there  have  primarily  operational  backgrounds 
and  they're  well-suited  to  trying  to  tease  out  what  the  priorities  are  between  programs,  which 
bunch  could  get  funded  and  which  bunch  shouldn't." 

Although  these  were  common  to  JCIDS  and  PPBE,  many  of  these  items  are  strikingly  familiar 
with  those  identified  within  the  acquisition  system  described  in  Chapter  3. 


Possible  Root  Cause  or  Causal  Mechanism 

Emergent  Behavior  or  Effect  on  System 

Official  Process  not  followed;  Theory  not 
followed;  Effort  to  Circumvent  processes  made 

Schedule  delays;  inevitably  certain  process 
aspects  must  be  followed  or  revisited 

Politics 

Program  turbulence;  churn  in  changing 
priorities,  program  forecasts,  budgets, 
schedules; 

Table  6:  Common  issues  identified  by  individuals  in  JCIDS  and  the  user  community 


Process  Discipline 

An  area  of  frustration  for  both  the  user  community  and  those  responsible  for  the  JCIDS  process 
dealt  with  the  official  processes  in  place  for  Acquisition.  "My  opinion  is  that  if  people  would  spend  as 
much  energy  trying  to  work  within  the  system,  they'd  get  done  a  lot  quicker  than  trying  to  figure  out 
how  to  work  around  it,"  as  one  JCIDS  participant  remarked.  "Nine  times  out  of  10,  what  they  want  to  do 
is  not  by  the  book." 

Breakdowns  of  the  process  are  typically  assumed  to  be  the  result  of  taking  short-cuts: 

"Things  that  seem  to  not  do  well  going  through  the  JCIDS  process  are  because  they  didn't  do 
sufficient  analysis  to  justify  the  performance  attributes  of  that.  Or  they  didn't  do  sufficient 
analysis  to  prove  why  that  was  the  best  capability  suite  to  answer  a  given  set  of  gaps."  (JCIDS 
participant) 
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The  user  community  has  also  observed  the  lack  of  discipline  extends  beyond  JCIDS.  As  one  user 


put  it: "...  We  haven't  even  with  the  last  few  years  emphasis  on  capabilities  and  effects-based  planning 
operations;  we  really,  the  manner  in  which  we  plan,  allocate  and  execute  resources  hasn't  followed 
that." 

Politics 

"Our  instructions  that  dictate  what  we  do,  do  not  allude  to  the  political  realities  that  you 

typically  have  to  deal  with  within  these  communities."  This  observation  came  from  an  "end-user"  or  war 

fighter.  As  an  example,  one  CDD35  has  been  in  coordination  for  three  or  four  years.  "It's  not  so  much 

the  technical  requirement  as  it  is  the  politics  associated  with  the  system,"  said  one  JCIDS  participant. 

Some  users  recognize  their  limitations  with  respect  to  funding  programs-and  don't  like  it: 

"So  it's  an  influence  versus  control  [issue].  But  I  think  the  control  lies  with  AQX  ...  if  we  don't 
execute,  then  we've  lost  our  control.  That’s  why  we  have  internal  reviews,  monthly  execution 
reviews  and  internal  reviews  with  our  portfolio  management  people  on  a  repetitive  basis,  to 
make  sure  we're  spending,  or  our  programs  are  spending,  our  lead  commands36." 

Many  of  these  issues  were  similarly  echoed  by  members  of  the  acquisition  system. 


Possible  Root  Cause  or  Causal  Mechanism 

Emergent  Behavior  or  Effect  on  System 

No  resources  ($s)  available  for  early  program 
exploration 

Overall  process  slowed;  analysis  poorly  done; 
later  phases  have  to  take  time  and  money  to 
do  the  job 

Process  can't  say  "no"  to  new  programs; 

beholden  to  sunk  costs 

Too  many  items  in  the  pipeline;  other  systems 
assume  each  other  will  exercise  refusal  rights 

Table  7:  Issues  identified  by  individuals  within  JCIDS  only 


35  CDD:  Capability  Development  Document;  typical  timeline  for  approval  is  much  shorter 

36  This  quote  may  seem  strange  as  the  user  implies  that  it  is  responsible  for  spending  money.  In  this  case,  the  user 
is  highlighting  what  happens  if  the  associated  acquisition  organization  is  not  able  to  spend  money  properly- 
according  to  goals  and  published  expenditure  targets-those  moneys  are  at  risk  for  being  redirected  elsewhere  by 
AQX.  If  money  is  taken,  schedules  and  scope  of  work  are  at  risk  of  being  changed.  This  is  how  the  user 
organization  "loses  control"  of  these  moneys. 
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Poor  resourcing  up-front 

The  "process"  for  a  new  program  requires  a  great  deal  of  analysis  at  the  beginning  of  any  effort. 

However,  the  way  the  system  is  currently  set-up  has  several  built-in  disincentives. 

"If  it's  an  established  program,  you  can  either  pull  it  out  of  hide37  or  POM  for  it.  But  if  it's 
something  that  doesn't  have  a  PE  yet,  especially  if  it's  something  that's  going  to  turn  into  an 
ACAT  III  or  a  small  program,  then  you're  really  struggling  to  try  and  pull  those  resources 
together.  Until  you're  a  program,  you  don't  have  a  PE.  Without  a  PE,  you  don't  have  a  program 
office,  you  don't  have  money,  you  don't  have  nothing,  nobody  to  help  you,  and  well,  you're  all 
the  way  up  to  milestone  B38  before  you  really  become  a  program."  (JCIDS  official) 

This  quote  plays  off  of  the  last  paragraph's  quote: 

"Good  analysis  isn't  cheap,  and  it's  not  exactly  timely.  It  takes  a  while  to  do  the  types  of 
analyses,  especially  when  you  talk  about  ACAT  I  programs,  you  know,  you're  looking  at,  typically 
like  18  months  to  do  an  analysis  of  alternatives.  That's  a  long  time  for  a  program  and  while 
you're  doing  that  analysis  of  alternatives,  you  could  be  losing  money,  you  could  be  bleeding 
money  off  the  program.  .  .  .  The  MAJCOM's  priorities  can  change.  You  know,  because  they're 
the  ones  ...  to  be  clear,  typically,  when  you're  at  that  stage,  you  don't  necessarily  have  a 
program  yet,  you're  just  out  there  doing  a  quest  for  the  truth.  So  you  know,  who's  doing  that? 
Who's  footing  the  bill  for  that?  The  MAJCOM  has  to  be  willing  to  foot  the  bill  for  it  and  if  they 
have  other  priorities  or  things  change  .  .  .  their  priorities  change  or  change  for  them,  that's  going 
to  get  pushed  by  the  wayside,  it's  going  to  delay  coming  to  the  conclusion  that  you  need  to 
come  to."  (JCIDS  participant) 

Program  Gate-keeping 

Regarding  new  programs,  there  are  many  ways  that  one  can  be  started.  On  the  Air  Force  side  of 
the  JCIDS  process,  according  to  interviewees,  the  Air  Force  does  not  require  money  to  be  allocated  for  a 
requirement  to  go  through  the  process.  However,  it  is  required  for  a  document  that  is  going  through 
the  joint  process  of  JCIDS.  This  leads  to  many  opportunities  for  small  efforts  to  be  started,  since  they 
typically  will  escape  joint  scrutiny,  and  seek  additional  funding  through  the  official  system  as  progress  is 
made.  As  more  money  is  spent,  the  more  difficult  it  is  to  prevent  the  program  from  being  finished-even 
though  it  was  never  officially  sanctioned  or  has  a  heritage  in  the  traditional  JCIDS  process. 


Pull  it  out  of  hide:  an  expression  meaning  you'll  pay  for  it  somehow  out  of  your  existing  resources. 
Milestone  B  is  the  official  "start"  of  any  acquisition  program 
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Possible  Root  Cause  or  Causal  Mechanism 

Emergent  Behavior  or  Effect  on  System 

Moneys  are  treated  differently  depending 
upon  execution,  budgeting,  or  planning  phases 

Mismatches  in  financial  priorities  between 

PPBE,  Acquisition,  and  user 

Not  enough  resources  for  programs 

Financial  shell  games;  spreading  out  dollars 
across  multiple  years;  extending  program 

schedules 

Budget  drills,  timing,  PPBE  complexity 

No  margin  for  stochastic  events;  inevitable 
delays;  constant  churn  or  program  turbulence; 
little  financial  stability 

Table  8:  Issues  identified  by  individuals  within  PPBE  only 


Money  differences  in  acquisition  phases 

The  way  the  PPBE  is  structured  deliberately  separates  the  way  money  is  used,  depending  upon 

the  timeframe  involved.  But  this  separation  also  spurs  behaviors  to  play  the  strengths  and  weaknesses 

of  each  organization  off  of  each  other  as  the  following  quote  illustrates: 

"A8  and  AQ  at  the  headquarters  have  the  majority  of  the  influence  over  what  money  is  going  to 
be  spent  where.  AQ,  from  the  perspective  of  a  kind  of  'go,'  'no  go,'  if  there  is  enough  money  to 
execute  the  program  or  not,  obviously,  if  you  cut  a  program  past  a  certain  point,  then  AQ 
declares  we  can't  get  there  from  here,  we’re  done.  So  A8  is  constantly  trying  to  find  that 
boundary,  and  trying  to  spread  the  dollars  around  as  much  as  they  can  to  get  as  much  capability 
as  they  can."  (PPBE  participant) 

The  following  quote  is  an  example  of  one  PPBE  participant  suggesting  program  turbulence  is 
precipitated  by  another  organization: 

"Budget  drills  often  originate  in  the  office  of  AQX  because  they're  looking  across  investment 
funds  and  trying  to  find  money.  .  .  .  Where  AQX  has  the  primary  role  ...  in  the  actual  years  of 
execution.  So  if  the  Air  Force  is  already  in  possession  of  the  money  and  we're  executing  and 
spending  those  dollars,  they  have  a  lot  more  leeway  and  try  to  work  with  the  Comptroller  to 
move  those  dollars  around."  (PPBE  participant) 

Not  enough  resources 

This  extended  exchange  between  a  PPBE  participant  and  the  interviewer  is  enlightening  as  it 
gives  insight  into  some  of  the  games  that  are  played  in  budgeting,  especially  in  the  Air  Force's  fiscally 
constrained  environment: 
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Interviewee:  "A  lot  of  times  we're  just  afraid  and  say  okay  were  not  gonna  judge  this  in  the 
POM;  it’s  gonna  be  an  execution  year  bill39.  That  just  becomes  an  O&M40  problem.  Interviewer: 
Then  O&M  needs  to  find  money  to  pay  for  it  during  the  execution  year?  Interviewee:  It's  not  in 
the  POM  but  you  still  get  an  O&M  budget  every  year  just  for  whatever." 

Interviewer:  "How  is  it  tracked?" 

Interviewee:  "It  would  come  out  in  the  POM,  you  know,  when  you  publish  the  POM  there  will  be 
a  line  in  there  that  says  okay,  we  didn't  fund  it.  And  you  know,  because,  you  know  it's  not 
funded  during  execution,  so  then  the  FM  guys  will  see  that  and  say  okay,  we’ve  got  to  fund  this 
during  execution.  So  that'll  come  back  to  the  POM,  so,  whoever  submitted  that,  that  funding 
request,  they'll  get  the  data  back  and  okay,  you  didn't  get  funded  and  the  note  was  you  got  to 
fund  it  in  execution.  So  then  you  have  a  choice,  okay,  well  do  I  use  my  execution  year  dollars  to 
fund  it  or  do  I  just  not  do  it?  There  are  a  lot  of  must  pay  bills,  you  do  that,  because  you  know  it's 
a  must  pay  and  so  if  you  just  deferred  to  execution  year,  someone's  got  to  pay  for  it 
somewhere. 

Interviewer:  "And  then  to  fund  these  programs,  people  start  looking  for  similar  programs  that 
can  be  used  as  a  source  to  pay  these  execution  year  bills." 

Interviewee:  "This  is  one  of  the  purposes  of  the  spring  and  fall  execution  reviews." 

A  wonderful  understatement  by  a  PPBE  participant  captures  the  essence  of  the  system,  "There 
is  no  extra  money." 

Money  Drills 

Budget  drills  happen  all  of  the  time.  This  is  a  common  theme  among  most  of  the  interviewees. 

The  following  quote  from  a  participant  in  the  PPBE  is  indicative  of  the  complexity  and  velocity  of  the 

PPBE  that  contributes  to  the  churn  in  the  overall  system: 

"For  instance  ...  I'm  doing  unfunded  drills  for  '08  in  3400  dollars.  ...  I  just  got  a  heads  up  that 
we’re  going  to  be  putting  together  the  Chief  of  Staff  of  the  Air  Force's  unfunded  part  of  this  for 


39  A  term  reserved  for  something  that  must  be  paid,  but  in  order  to  balance  the  budget,  is  made  zero.  It  counts 
upon  the  fact  that  a  program  somewhere  will  likely  face  trouble  executing  all  of  its  moneys  during  the  execution 
year  and  can  be  paid  through  this  means. 

40  Operations  and  Maintenance.  In  this  context,  it  refers  to  the  moneys  that  are  only  authorized  for  1  year's 
obligation  and  spending  and  have  somewhat  greater  flexibility  in  disbursement  options. 
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FY  '09.  ...  So  I  get  a  tasker41  for  the  end  of  the  month.  We’re  starting  to  put  our  exhibits42 
together  for  '09.  .  .  .  We  just  got  done  with  the  President's  budget.  We  just  got  done  with  the 
PDM's43  and  PPD's44  for  '09.  Okay,  so  we  just  got  done  with  that.  We  are  working  hard  on  the 
'10  POM.  And  every  Wednesday  going  out,  starting  next  Wednesday  for  three  weeks,  we  have 
meetings  with  the  Air  Force,  with  all  the  MAJCOMs  on  the  '10  POM.  On  top  of  that,  the  panels 
are  starting  their  MAJCOM  reviews  next  week  for  the  '10  POM.  And  then  we’ll  go  into  the  PEM 
parades45  just  around  the  25th  of  January.  So  you're  constantly  churning  at  three  levels,  current 
year,  next  year's  execution  plan  and  then  the  FYDP46." 

Another  PPBE  participant  noted,  "Every  day  I'm  working  at  the  execution  year.  I'm  working  at 

the  next  fiscal  year,  and  I'm  working  in  the  FYDP." 

More  quotes  that  lend  support  for  the  constant  churn  the  system  exhibits: 

"Sometimes  we  slip  a  program  because  it's  early  to  need,  because  another  program  has  slipped. 
And  then  it  may  come  that  when  we  actually  get  to  those  years  then  that  something  else  has 
come  along  and  we  can  take  those  dollars  from  that  program.  So  yeah,  a  lot  of  times  it's,  well, 
this  program  is  underperforming  sort  of  a  slip  it  and  eventually  hopefully  we  can  kill  it."  (PPBE 
participant) 

"We  break  good  program  so  that  all  programs  feel  the  same  level  of  pain.  To  level  the  playing 
field.  I  mean,  it  seems  ridiculous  but  if  you  have  a  program  that's  really  executing  well  and  you 
have  one,  that's  the  disconnect,  I  can  level  them  out  so  they're  all  feeling  the  pain  evenly." 
(PPBE  participant) 

"So,  based  on  the  guidance  we  have  there  is  a  constant  churn  of  ideas  and  programs  and 
whether  or  not  a  program  is  executing  correctly,  you  know,  there's  a  constant  churn,  okay.  But 
we  just  take  a  position  and  time  outside  the  Air  Force,  on  even  numbered  years,  and  then  on 
odd  numbered  years,  we  can  change  things,  but  we  can't  start  new  programs  on  odd  numbered 
years.  We  have  to  zero  balance  in  odd  numbered  years,  and  there's  no  new  starts."  (PPBE 
participant). 


41  Slang  for  a  task  or  assignment 

42  Documentation  supporting  funding  recommendations  for  a  budget  submission  (aka  POM) 

43  Program  Decision  Memorandums 

44  Program  Planning  Document 

45  PEM  Parade:  slang  for  reviews  of  the  PEs  managed  by  a  PEM  across  all  years  of  spending  and  budgeting 

46  Future  Years  Defense  Plan 
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Other  issues 


Six  additional  topics  emerged  from  the  analysis  that  didn't  align  well  with  the  reporting 
construct  above.  Instead,  these  tended  to  be  a  direct  result  of  the  interview  questions  seeking  to 
validate  or  refute  preconceived  notions.  These  areas  are:  system  timelines;  system  capacity;  process 
coordination;  accountability  and  power  distribution;  definition  of  portfolios;  and  process  quality  and 
precision. 

Timelines  of  the  System 

During  the  course  of  these  interviews,  many  references  to  temporal  dynamics  of  the  overall 

system  were  noted.  Samplings  of  them  are  listed  below: 

"[If]  it’s  going  to  go  all  the  way  to  the  JROC,  I'll  tell  them  15  to  18  months....  but  practical 
experience  is  that  it  takes  longer  than  the  book  says.  And  if  they  don't  run  into  problems,  15  to 
18  months  is  probably  reasonable.  If  it's  not  a  joint  issue,  especially  if  it's  an  independent 
document,  6  to  9  months,  depending  on  how  hard  they  want  to  push."  (JCIDS  participant) 

"The  first  step  in  JCIDS  is  the  analysis,  and  you  do  an  ICD  and  all  this  stuff.  That  will  take  you  a 
year  or  two,  typically  two  years."  (JCIDS  participant) 

"The  requirements  process  timeline.  Number  one,  the  RSR  is  the  first  step.  Number  two,  if  it  is 
an  ACAT  I,  it  will  take  just  shy  of  a  year  to  get  done,  and  that's  if  things  go  normally.  Number 
three,  if  it  is  important  to  a  major  command,  they  could  squeeze  it  down  to  seven  or  eight 
months  (plus  some  star  alignment)47  as  the  AFROCC  meets  one  time  per  month,  the  JROC  more 
often).  It's  the  catch  the  bus  analogy.  If  you  miss  the  meeting,  you  have  a  built-in  delay."  (JCIDS 
participant) 

"A  non-ACAT  program  or  service  unique  program  saves  at  least  one  month."  (JCIDS  participant) 

"An  ACAT  III  program  stops  at  the  AFROCC.  ACAT  II  goes  to  A35  for  approval.  ACAT  I,  but 
internal  to  the  Air  Force,  stops  at  the  AFROCC  and  gets  the  chief's  signature.  Plus  staffing  time. 
Usually  two  months  savings  when  not  joint."  (JCIDS  participant) 

"It  takes  about  a  year  to  get  an  ICD,  and  then  two  or  three  years  building  to  10  years  or  more  to 
get  a  program."  (JCIDS  participant) 


Referring  to  Generals  ("the  stars")  and  getting  them  all  together  in  one  room  at  a  time. 
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'The  timeline  for  money  on  a  new  initiative  is  approximately  2  to  3  months."  (JCIDS  participant) 


"April  is  the  timeframe  for  the  spring  program  reviews48."  (JCIDS  participant) 

Capacity  of  the  System 

During  the  course  of  these  interviews,  many  references  to  process  capacities  of  the  overall 

system  were  noted.  They  were  not  reported  as  capacities  but  further  reflection  indicates  these  can  be 

construed  as  such.  Samplings  of  them  are  listed  below: 

"Typically,  well  have  about  20  JCIDS  documents,  somewhere  in  the  process  at  any  given  time. 
Some  of  those  make  it  all  the  way  through  the  system.  Some  of  them  get  abandoned  for  one 
reason  or  another.  Probably,  I  would  say  15  or  so  wind  up  getting  approved  each  year."  (JCIDS 
participant) 

"We  probably  see  about  10  a  month,  10  to  15  of  those  a  month,  that  we  have  to  take  care  of 
also."  (This  statement  refers  to  documents  originating  outside  of  the  major  command.)  (JCIDS 
participant) 

"It’s  normal  to  see  60  or  70  of  these  things  a  year. . ."  (at  the  Air  Force  level  office  for  JCIDS). 
(JCIDS  participant) 

The  following  quote  deserves  special  attention.  It  implies  an  acknowledgement  of  capacity 
issues,  but  also  abdicates  responsibility  for  managing  that  capacity  and  relies  upon  an  outside 
organization  to  do  that.  This  was  from  a  person  within  JCIDS,  and  closely  aligned  with  the  user 
community  as  well: 

"Okay,  I  got  10  people,  so  I  may  get  10  people's  worth  of  work.  But  I'm  going  to  keep  giving 
them  work  and  I'm  going  to  give  them  the  work  of  50  people,  but  knowing  that  I'm  only  going  to 
get  10  hours.  So  yeah,  that's  what  I  meant  by  recognizing  there  is  a  finite  level  of  capacity,  .  .  . 
but  that  doesn't  mean  I'm  not  going  to  give  them  50  requirements  even  though  I  know  they  can 
hold,  handle  10.  I'm  still  going  to  give  them  all  50  requirements.  And  they'll  work  it  in  their 
priority  unless  I  say,  okay,  I  gave  you  50  but,  you  know,  I  want  you  to  work  35  to  45  right  now.  I 
need  those  right  now.  And  then  maybe  you'll  get  to  the  other  ones.  .  .  .  Well,  if  they're 
important  to  somebody,  it'll  bubble  up  again,  otherwise  it'll  just ...  it  won't  completely  go  away, 
it'll  still  be  there,  and  maybe  somebody,  you  know,  in  a  month  or  so,  say,  you  know,  I've  got  this, 


Depending  upon  the  organization,  any  month  in  the  early  part  of  a  year  would  be  their  time  for  the  Spring 
Execution  Review 
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is  this  still  important,  do  we  still  need  to  do  that  and  we'll  all  go,  yeah,  we  may  still  need  that. 
Then,  you  know,  it’ll  go  back  in  there  again." 

Coordination 

This  is  a  specific  issue  only  for  JCIDS,  but  has  some  interesting  process  implications  for  the  larger 

enterprise.  First  is  the  idea  relating  to  quality  measures.  Second  is  the  inherent  uncertainty  the  design 

of  this  process  introduces,  and  third  is  the  potential  for  a  misappropriation  of  power. 

"JCIDS  I  think  has  a  lot  of  problems,  but  just  the  coordination  process,  I  think  is  one  of  them  in 
that  when  you  have  to  please  everybody,  you  wind  up  with  mediocrity  quite  often."  (JCIDS 
participant) 

"And  I  guess  in  what  I  do,  and  half  of  these  documents  get  through  the  system,  probably  the 
biggest  risk  is  the  coordination  process.  You  just  don’t  know  how  long.  When  you  start  one  of 
these  documents,  you  got  some  suspense  that  you're  looking  at.  Like  milestone  B  is  going  to  be 
on  this  day.  I  need  to  have  the  document  approved  by  then,  and  there's  a  risk  in  not  completing 
the  document  and  probably  the  coordination  process  is  the  biggest  driver  on  that,  because  you 
just  don't  know  what  people  are  going  to  toss  at  you."  (JCIDS  participant) 

"I  already  mentioned  that  when  you  coordinate  these  documents,  there's  no  control  over  what 
kind  of  comments  can  come  in  from  anybody  who  looks  at  it.  And  somebody  says  this  is  a 
'critical  comment,'  it  brings  the  whole  process  to  a  screeching  halt,  till  you  can  change  their 
mind.  Or  capitulate."  (JCIDS  participant) 

Accountability  and  Power 

A  few  individuals  commented  on  the  way  the  system  operates  at  large.  Ironically,  all  of  these 

comments  were  made  by  individuals  outside  of  the  system  -  representatives  of  the  user. 

"The  nature  of  the  PPBE  in  JCIDS  is  that  it  takes  years  and  years  to  get  anything  done,  so  10 
years  into  this  program  and  nothing  of  substance  has  happened,  who  is  blamed?  A  lot  of  people 
got  fat  OPRs49  along  the  way,  but  nothing  got  built." 

"It's  muddy  because  there's  umpteen  levels  of  management...  if  you  have  three  people  doing 
the  job  of  one,  it  not  only  won't  be  better,  it'll  be  worse." 


49  OPR:  Officer  Performance  Report.  This  quote  addresses  the  yearly  evaluation  and  incentive  structure  that  exists 
within  the  acquisition  system  and  suggests  that  lots  of  people  received  exceptional  performance  reports  when  not 
really  doing  anything. 
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"If  I  create  a  system  that  is  so  complex,  tax  code-ish  complex  that  I  have  to  have  specialists 
guide  me  through  it,  who  should  really  be  building  a  radio?  An  engineer  who  understands  how 
to  build  radios,  or  people  who  are  experts  in  the  process?  The  people  with  all  the  power  are  the 
experts  in  the  process.  That  is  a  big  problem.  The  process  is  much,  much  too  complex  and  if 
people  who  have  all  the  power  are  the  people  who  become  the  lawyers,  the  experts  in  the 
system,  that's  no  way  to  run  a  railroad." 

"The  subject  matter  experts  aren't  there.  It's  the  person  who  is  good  with  rules  that  wields  the 
power.  Somehow  we  need  to  get  the  subject  matter,  the  actual  engineers  who  build  things,  tied 
into  that  process,  to  keep  bad  decisions  from  being  made  by  people  who  are  experts  in  the  rules 
of  money,  but  are  not  necessarily  experts  in  the  thing  that's  being  built." 

Portfolios  defined 

While  finding  a  definition  of  portfolios  within  the  Air  Force  was  one  goal  of  these  interviews, 
after  several  of  them,  a  clear  conclusion  could  be  made:  a  portfolio  means  something  different  to  almost 
every  person.  "A  portfolio  is  just  a  way  of  binning  systems."  "A  portfolio  is  a  grouping  of  programs." 

But  all  recognized  that  it  could  be  organized  a  million  different  ways--through  "different  slices  and 
dices,"  thereby  diluting  the  meaning  and  power  of  managing  by  portfolios. 

Process  Quality  and  Precision 

This  topic  holds  a  wide  variety  of  opinions,  but  also  sheds  some  light  with  a  fair  assessment  of 
the  quality  and  precision  of  the  overall  system. 

Comments  on  the  overall  process: 

"We  are  guessing  what  the  world  will  look  like  in  ten  or  fifteen  years." 

"We  have  champagne  tastes  on  a  beer  income." 

Comments  on  JCIDS: 

"The  quality  of  requirements  documents  is  fairly  uniform  from  the  various  major  commands 
throughout  the  Air  Force.  It  is  a  discipline  process." 

"The  JCIDS  process  as  a  whole  is  too  long  because  they  keep  adding  boards  and  reviews,  and 
then  on  the  other  side  of  their  mouth  they  say  it  takes  too  long." 

"So  the  guys  here  wind  up  probably  ten  days  to  weeks  or  so  they  have  to  look  at  them. 
Sometimes  that's  enough.  But  some  of  these  things  are  three,  four  hundred  pages.  Personally, 
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if  they  want  an  honest  review,  I  don't  think  there's  enough  time  given  to  the  real  experts  to  look 
at  it." 

Comments  on  the  PPBE: 

.  .  Why  do  they  do  what  they  do?  Well,  I  guess  the  most  obvious  answer  would  be  that  when 
they  need  to  get  money,  they  take  money  somehow.  If  they  don't  do  it  intelligently,  they,  for 
example,  say  okay,  everybody  gives  five  percent  or  everybody  gives  fifteen  percent,  whatever 
the  number  is  that  you've  got  to  get  to  the  bottom  line  with  ...  in  some  cases,  you're  taking 
money  out  of  management  reserve  and  maybe  it  won't  hurt  anybody,  in  other  cases,  you're 
killing  somebody.  Maybe  they're  already  behind.  So  that  kind  of  salami  slice  approach  can  get 
you  into  trouble.  But  when  you  don't  have  much  time  to  really  figure  out  things  or  if  you  can't 
get  real  good  information  from  the  acquisition  guys  who  have  the  numbers,  you  do  things  like 
that  because  you  got  to  .  .  .  the  clock  says  it's  five  minutes  to  twelve,  what's  your  answer,  you 
got  to  come  up  with  something.  So  probably,  there’s  a  lack  of  information,  probably  there’s  a 
lack  of  time  and  there’s  a  need  to  do  something  and  they  do  it." 

Chapter  Conclusion:  Implications  of  this  study 

Based  on  the  observations  and  results  of  this  small  study,  many  behaviors  of  the  larger 
acquisition  system  have  been  listed  and  identified-often  as  a  problem  or  as  a  consequence  of 
something  else.  It  is  much  easier  to  acknowledge  many  problems  within  acquisition  are  often  times 
formed  well  outside  of  the  original  boundaries  of  the  "little  a"  acquisition  system.  Furthermore,  this 
observation  was  repeatedly  validated  by  the  interviewees  working  in  the  systems  outside  of  acquisition. 
Analysis  of  these  systems  also  supports  the  idea  that  rational  actors  exist  throughout  the  system  and 
behave  accordingly,  which  often  means  that  without  other  influences,  people  optimize  locally  and  do  so 
rationally  within  the  construct  of  their  immediate  system.  In  this  regard,  the  "system"  seems  to  be  the 
customer  of  many  of  the  efforts  of  the  people  working  the  acquisition  of  systems  for  the  US  Air  Force 
rather  than  the  actual  airman  in  combat  or  operational  environments,  e.g.  the  war  fighter.  After  a 
careful  examination  of  the  PPBE  and  JCIDS;  however,  no  clear  conclusions  can  be  drawn  except  that  the 
system  often  behaves  at  odds  with  expected  outcomes.  It  is  also  naive  to  think  that  root  causes  or 
main  causal  mechanisms  for  deviations  from  outcome  measures  of  programs,  in  particular  cost  and 
schedule,  would  be  so  easily  identified  using  these  interviews.  It  does,  however,  lend  credence  to  a 
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growing  body  of  evidence  that  suggests  large,  complex  systems  often  have  emergent  behaviors  that  can 


be  counterproductive. 

Further,  the  concept  of  managing  programs  through  portfolios  is  immature  and  portfolio  risk 
understanding  is  primitive  outside  acquisition.  While  everyone  has  ideas  about  risk  &  portfolios- 
intuition  says  we  should  be  able  to  do  this— this  idea  wasn't  borne  out  in  the  interviews  as  answers  were 
all  over  the  map. 

Development  of  a  model  of  the  overall  US  Air  Force  PD  process,  including  those  portions  of 
portfolio  responsibility  and  authority  residing  outside  the  acquisition  system,  is  a  logical  next  step 
towards  understanding  emergent  system  behaviors.  In  the  following  chapters,  a  framework  and  model 
will  be  introduced  that  attempts  to  rationally  characterize  the  entire  system,  with  its  emergent 
behaviors,  allowing  for  additional  testing  and  analysis.  A  simulation  of  the  enterprise  and  analysis  of 
enterprise  outcomes  may  shed  light  on  the  efficacy  of  current  efforts  to  reform  and  administer  the 
current  processes  and  existing  system  portfolios. 
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CHAPTER  5  --  A  MODEL  OF  THE  ENTERPRISE  ACQUISITION 
SYSTEM 

In  the  two  studies  previously  described,  both  members  of  the  acquisition  corps  and  members  of 
PPBE  and  JCIDS  expressed  concerns  and  frustrations  about  the  overall  behavior  of  the  system.  In  order 
to  understand  these  behaviors,  development  of  a  model  characterizing  the  entire  system  (the  big  "A"  of 
Acquisition)  was  undertaken.  Key  to  the  development  would  be  to  accurately  characterize  all  of  these 
issues. 

One  of  the  more  important  modeling  issues  was  a  desire  to  keep  the  model  as  simple  as 
possible  yet  accurate  enough  to  capture  enough  information  to  construct  a  model  that  would  accurately 
depict  the  overall  Acquisition  system  behavior.  A  quick  review  of  existing  models  in  the  literature 
dealing  with  many  of  the  problems  of  acquisition  revealed  no  overall  approach  to  the  entire  system. 
Many  of  these  models  picked  out  a  very  specific  issue  like  cost  growth  during  the  technology 
development  phase  and  derived  a  predictive  model  from  the  database  of  a  few  programs  examined. 
Others  looked  at  schedule  growth  or  requirements  growth  and  hypothesized  causal  factors  based  upon 
a  sampling  of  different  programs.  Still  others  looked  at  specific  policies  and  their  impacts  upon 
contracts  or  other  items  of  acquisition  interest.  See  more  information  about  these  studies  in  Appendix 
A. 
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Key  Processes  of  US  Air  Force 
Acquisition 
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Figure  20:  A  Holistic  View  of  the  Acquisition  System 

The  two  studies  conducted  as  a  part  of  this  research  further  emphasized  the  need  for  a 
comprehensive  or  a  holistic  model  of  the  entire  acquisition  system.  However,  it  was  not  clear  exactly 
how  to  construct  such  a  model.  The  system  consists  of  the  three  processes  depicted  above.  It  involves 
both  resource  management  as  well  as  selection  of  systems  for  development.  It  is  explicit  in  the 
distributed  responsibilities  among  various  organizations  throughout  the  system.  Any  model  would  need 
to  be  able  to  account  for  these  items. 

A  key  breakthrough  occurred  during  the  analysis  of  the  interviews  of  the  second  study.  During 
these  interviews,  each  interviewee  was  pressed  about  different  outcome  measures  of  the  particular  job 
or  task  they  did:  How  long  did  it  take  to  do  their  job?  What  was  the  typical  task  like?  The  answers 
were,  almost  without  question,  uniform  in  their  response,  "It  depends."  It  depends  upon  the  program 
being  talked  about;  it  depends  upon  the  sponsor  or  champion  of  the  program;  it  depends  upon  the 
technology  or  the  money  or  the  structure  of  the  acquisition,  etc.,  etc.,  etc.  During  the  course  of  the 
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conversation,  however,  interviewees  eventually  were  able  to  abstract  answers  into  a  time  range  or  a 


time  distribution.  Decisions  and  key  process  checkpoints  were  abstracted  into  probabilities. 

This  sparked  an  idea  of  taking  this  information  and  seeing  if  it  was  possible  to  construct  an 
overall  model,  at  the  same  general  level  of  abstraction,  for  the  entire  system  from  the  information 
provided  by  the  interviewees.  It  relied  upon  the  basic  understandings  of  risk,  probabilities  and 
occurrence,  and,  therefore,  upon  further  examination,  many  of  the  first  study's  interviews  contained  a 
similar  level  of  abstracted  information  since  the  initial  focus  of  that  study  was  to  understand  risk  in 
acquisition.  Between  these  two  studies,  the  overall  impressions  left  by  the  interviewees  tended  to 
confirm  the  underlying  supposition  that  the  behaviors  decried  within  acquisition  are  often  the  result  of 
emergent  behaviors  of  the  overall  enterprise  system. 

The  initial  starting  point  for  building  a  model  of  the  entire  acquisition  system  then  was  to  take 
process  information  from  official  sources,  like  AF  and  DOD  Instructions  on  JCIDS,  PPBE,  and  Acquisition 
and  put  these  on  paper.  Each  of  them  presented  an  idealized  process  flow,  as  per  the  exhibited 
diagrams  in  the  previous  chapters,  but  offered  very  little  details  on  the  interactions  and  interfaces 
between  the  processes.  The  various  interviews  were  used  to  fill  in  those  details  and  bridge  the  gaps. 
Arrows  connecting  activities  and  processes  were  drawn.  Based  upon  various  official  documents  and 
process  flow  information,  a  time-dependent  process  flowchart  was  constructed  by  stringing  together 
the  various  process  steps  and  decision  points  within  the  system.  The  resulting  model  is  straightforward 
as  it  consists  of  various  processes,  decision  points,  and  the  accompanying  logic  to  walk  through  the 
entire  process  for  a  program  in  development. 

Model  design  and  depiction 

Based  upon  the  discussion  in  Chapter  two  about  modeling  and  simulation,  a  model  capable  of 
discrete-event  simulation  was  chosen  as  opposed  to  other  modeling  choices.  One  of  the  conscious 
decisions  made  about  the  depiction  of  the  model  was  to  put  it  in  similar  terms  as  to  what  most 
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acquisition  personnel  are  accustomed  to.  This  work  should  be  of  value  to  the  Acquisition  professional 


and  the  DOD  in  general.  The  Defense  Acquisition  University  has  prepared  an  instruction  aid,  nicknamed 
the  "wall  chart,"  that  is  used  to  educate  both  acquisition  personnel,  as  well  as  others  about  the  defense 
acquisition  system.  The  wall  chart  presumes  the  object  of  interest  is  a  single  acquisition  program.  It 
does  not  look  at  multiple  programs  at  once,  although  one  could  extrapolate  and  envision  the  complexity 
such  an  arrangement  would  bring.  The  chart  is  divided  into  sections  or  "swim  lanes"  corresponding  to 
the  functional  domains  of  the  overall  system.  The  little  "a"  of  acquisition  is  emphasized  in  this 
depiction-as  a  result  of  the  primary  purpose  of  the  chart-along  with  other  items.  There  are  4  major 
swim  lanes--depicted  horizontally-representing  the  user,  JCIDS,  acquisition,  and  the  PPBE.  The 
processes  depicted  cross  these  boundaries,  interact,  and  imply  a  temporal  aspect  of  the  process  from 
left  to  right  (see  the  figure  below).  The  output  of  the  model  consists  of  a  record  of  time  elapsed  for  a 
single  program  and  also  reports  proposed  time  durations  within  the  model  to  allow  for  further  analysis 
and  comparisons  with  the  actual  simulated  results.  The  model  is  easily  extendable  to  do  the  same  for 
program  costs.  Because  there  is  a  tight  coupling  between  program  duration  and  program  costs, 
program  costs  were  not  explicitly  tracked.  This  assumption  can  be  explored  further  in  future  work. 
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Figure  21:  The  "Wall  Chart"  of  the  Defense  Acquisition  System  (December  2008  version) 

Based  upon  these  reasons,  the  developed  model  is  similar  in  format  and  has  many  of  the  same 
characteristics  as  the  figure  above. 


Model  Scope 

Another  important  consideration  was  to  establish  the  proper  scope  of  the  model.  As  described 
earlier,  the  big  "A"  of  Acquisition  consists  not  only  of  three  large  interacting  processes  divided  along 
functional  lines,  but  also  along  a  temporal  scale-from  an  initial  idea  through  the  eventual  retirement 
and  disposal  of  a  system. 

Such  a  system  is  huge  in  scale  and  scope,  but  as  the  primary  purpose  of  this  research  is  about 
the  acquisition  of  weapon  systems,  the  exclusion  of  the  sustainment  phase  seemed  reasonable. 

Further,  the  production  phase  (post  MS-C)  was  excluded  as  by  that  time  most  of  the  costs  for  the  design 
and  development  of  the  system  have  been  incurred.  The  following  figure  illustrates  the  scope  of  the 
model. 
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A  Representation  of  the  Enterprise  of  “Cradle  to  Grave”  Acquisition  in  the  US  Air 

Force 


Swim  Lane 

Pre-MS 

A  (Concept 
Refinement) 

Pre-MS  “B” 

(Technology 

Development) 

Pre-MS  “C” 

(System 

Development  & 
Demonstration) 

Pre-Full  Rate  Operations  and 

Production  Sustainment 

(Production  & 

Deployment) 

User 

Requirements 

r 

> 

Money 

Scope  of  Model 

Acquisition 

Contractor 

Figure  22:  Model  Scope  in  Relation  to  the  Overall  Acquisition  System 

The  user  "swim  lane"  is  shown  only  to  acknowledge  the  role  the  user  plays  in  the  process,  but  is 
excluded  in  the  model's  scope  as  the  Requirements  swim  lane  acts  as  a  surrogate  for  the  user  by  driving 
the  requirements  for  systems.  The  contractor  swim  lane  is  added  to  the  model  to  acknowledge  the  role 
contractors  play  in  the  acquisition  system.  This  portion  was  added  based  upon  the  author's  experience 
regarding  its  interaction  with  acquisition  and  would  be  used  to  help  account  for  the  uncertainties  that 
exist  in  the  overall  execution  of  development  contracts,  such  as  technical  difficulties,  changing 
requirements,  and  other  issues. 

Furthermore,  the  acquisition  system  categorizes  programs  going  through  the  system  using  a 
series  of  Acquisition  categories  (ACAT).  See  Chapter  2  for  a  more  detailed  discussion.  ACAT  I  programs 
are  typically  the  largest  or  the  most  politically  sensitive.  ACAT  II  programs  typically  are  software 
intensive  and  have  special  requirements.  ACAT  III  programs  don't  qualify  in  either  of  the  other  ACAT 
categories  and  are  usually  much  less  money  and  less  politically  sensitive.  These  are  all  known  as 
"Programs  of  Record."  There  are  a  handful  of  ACAT  I  programs,  a  few  more  ACAT  II  programs  and  many 
more  ACAT  III  programs  in  existence  at  any  given  time.  Additionally,  programs  that  don't  meet  any  of 


109 


the  criteria  defining  ACATs  exist-  these  non-programs  of  record  are  monetarily  miniscule  in  comparison 


to  other  programs.  For  purposes  of  this  model,  only  ACAT  I,  II,  and  III  programs  will  be  included  in  the 
scope  of  the  model. 

Model  Symbology 

The  model  uses  terminology  from  Business  Process  Modeling  and  Value  Stream  Mapping.  For 
instance,  a  "rectangle"  is  a  task  or  process  with  a  given  time  distribution  associated  with  it,  represented 
by  a  triangular  distribution  of  low,  most  likely,  and  high  process  duration  time.  A  "diamond"  is  a 
decision  point  with  branching  probabilities  of  "yes"  or  "no"  or  other  alternatives.  An  "oval"  is  used  to 
represent  information  to  explain  items  within  the  different  processes  or  to  further  explain  the  model.  A 
"parallelogram"  shows  the  final  output  or  product  of  a  process  or  processes,  such  as  a  document,  a 
prototype,  or  a  final  delivery.  The  freeware  program,  Dia,  a  Microsoft  Visio-like  diagramming  tool,  was 
used  to  develop  the  initial  models  of  the  Acquisition  System. 

Pre-MSA  Pre-MSB  Pre-MS  C 


Figure  23:  Conceptual  model  of  the  Acquisition  Enterprise 

In  the  figure  above,  the  model  is  divided  into  three  distinct  phases.  The  swim  lanes,  from  top  to 
bottom  of  the  figure  are  marked  by  the  horizontal  lines.  The  top  swim  lane  depicts  the  JCIDS  process 
within  the  USAF  and  portions  of  the  DOD.  The  second  swim  lane  depicts  the  PPBE,  the  process  is 
identical  in  each  phase  and  is  a  continuous  process.  The  third  swim  lane  is  the  acquisition  system  and 
the  last  swim  lane  is  the  contractor  swim  lane.  The  Pre-Milestone  A  portion  of  the  model  shows  the 
heavy  activity  in  the  requirements  portion  of  the  model.  This  makes  sense  as  new  requirements  are 
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generated  in  this  portion  of  the  model.  Later  model  refinements  continue  this  trend  and  are  able  to 


accommodate  other  acquisition  programs  that  leap-frog  different  phases  of  development,  while 
establishing  a  "start"  to  these  programs  as  well. 

In  the  Pre-Milestone  B  portion  of  the  system,  the  Acquisition  system  takes  on  a  more  defined 
and  larger  role  and  finally,  in  the  Pre-Milestone  C  portion  of  the  system,  both  the  contractor  and 
acquisition  swim  lanes  have  the  most  activity  as  they  prepare  a  system  for  delivery  ready  to  enter 
production.  The  bulk  of  the  extra  activity  in  the  Pre-Milestone  C  version  relates  to  fabrication,  test  and 
evaluation  activities  of  the  system  in  development. 

A  printed  version  of  this  conceptual  model  on  a  roll  of  poster  paper  is  about  fourteen  feet  long 
by  four  feet  wide.  Therefore,  to  further  illustrate  the  structure  of  the  model,  a  closer  look  at  one 
portion  of  the  model  will  be  made.  For  convenience,  the  very  first  portion  of  the  system  (in  the 
Requirements  swim  lane)  will  be  examined.  The  entire  description  of  this  conceptual  model  is  located  in 
Appendix  D. 


Requirements  Swimlane 


The  overall  conceptual  structure  of  the  model  is  easier  to  discern  with  this  figure.  The  smaller 
picture  in  the  upper  left  serves  as  a  reference  to  where  the  model  components  shown  are  in  relation  to 
the  entire  lifecycle,  as  well  as  the  rest  of  the  model.  It  is  represented  by  the  small  dark  square  in  that 
picture.  After  entry  into  the  system,  an  idea  or  program  meets  a  series  of  decision  points  (the 
diamonds)  as  well  as  process  activities  (rectangles).  Dependent  upon  the  probabilistic  outcome  of  the 
decisions  determines  which  path  is  taken.  As  the  processes  are  also  stochastic  in  nature,  the  time 
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required  to  complete  the  processes  varies.  Overall,  the  path  taken  and  time  required  from  start  to  finish 


potentially  could  be  different  each  and  every  time. 

Key  to  the  intellectual  richness  of  the  model's  design  is  that  every  decision  point,  every  process 
task,  where  possible,  is  thoroughly  documented  and  sourced.  In  cases  where  such  information  was 
unavailable,  secondary  sources  or  inferred  information  was  used.  Regardless  of  the  type  of  information 
used,  they  are  clearly  identified  in  the  detailed  model  documentation,  allowing  for  changes  and 
refinements,  as  required,  as  the  Acquisition  system  is  modified  over  time.  An  example  of  this  sourcing 
follows  below. 


RSR  -  Decision  Point 

-Sources:  Official  Docs, 
Interviews  (MAJCOM 
A5,  HQ  A3) 


Conduct  study  or  analysis 

-  Task 

-Sources:  Official  docs, 
Interviews  (MAJCOM  A5, 
HQ  A35) 


-Probability:  98% 


Funding  Available?  - 

Decision  point 

-Sources:  Interviews 
(MAJCOM  A5,  HQ  A3 
HQ  A35) 

-Probability:  80% 


-  Time  Distribution:  180  to 
360  days;  300  most  likely 

* 


Conduct  Study  or  Analysis 


Figure  25:  Close-up  view  of  three  elements  of  Pre-MS  A  Requirements  swim  lane 

This  figure  represents  three  individual  activities  in  an  early  portion  of  the  requirements  swim 
lane,  Pre-MS  A.  The  first  activity  is  the  RSR  or  Requirements  Strategy  Review.  This  is  a  review  gate  that 
determines  if  a  fledgling  idea  will  proceed  farther  in  the  overall  JCIDS  process.  It  was  documented 
through  both  the  literature  and  interviews.  In  this  case,  the  interviewees  indicated  that  there  is  a  98% 
probability  of  being  granted  approval  to  proceed  into  the  system,  and  part  of  this  was  that  the  previous 
process  steps  scrubbed  items  hard  before  allowing  an  idea  to  get  to  this  phase.  The  second  process 
check  was  regarding  available  funding  preparatory  for  the  third  step  shown.  According  to  interviews, 
the  probability  of  having  the  necessary  dollars  in  place  was  80%-again  due  to  the  heavy  institutional 
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scrub  given  an  idea  before  sending  it  to  the  RSR.  The  third  item  is  a  process  step  called  "Conduct  Study 


or  Analysis".  Through  both  official  documentation  and  interviewees,  it  was  determined  that  this  process 
required  anywhere  from  45  to  180  days  to  complete,  with  80  days  being  about  the  norm  for  most. 

This  is  the  way  in  which  the  conceptual  model  was  built  and  documented.  Validation  and 
Verification  of  the  model  will  be  discussed  in  the  next  chapter.  However,  the  following  figure  represents 
the  final  form  of  the  model  and  its  representation  in  Rockwell  Software's  Arena  Discrete-event 
Simulation  Software.  The  Research  version  of  the  software  was  used  to  complete  the  model. 
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Figure  26:  Final  Model  Representation 
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The  final  model  depiction  includes  the  learning  and  improvements  described  in  the  Verification 


and  Validation  chapter  of  this  work.  Graphically,  it  is  also  laid  out  a  bit  differently  than  the  first 
conceptual  model.  However,  the  only  substantial  difference  between  the  two  is  that  the  system  phases 
are  stacked  one  upon  the  other.  Pre-Milestone  A  with  the  attending  swim  lanes-only  three  swim  lanes 
as  the  contractor  swim  lane  does  not  participate  in  this  early  phase-is  at  the  top.  The  bold  line 
separates  it  from  Pre-Milestone  B  phase  with  its  swim  lanes  and  finally,  the  Pre-Milestone  C  phase  with 
its  swim  lanes  is  at  the  bottom  of  the  figure.  The  Pre-Milestone  A  phase  has  the  most  activity  in  the 
Requirements  swim  lane  and  the  Pre-Milestone  C  phase  has  the  most  activity  in  the  acquisition  and 
contractor  swim  lanes. 

There  is  one  main  entry  to  the  system  and  four  artificial  uncertainty  generators:  two  for  pre-MS 
B  and  two  for  pre-MS  C;  one  for  political  uncertainties,  the  other  for  other  uncertainties;  both  will  be 
described  in  detail  later  in  this  chapter.  There  are  29  different  exit  points  in  the  process.  A  successful 
completion  of  MS  C  is  just  one  of  those  29;  another  example  is  an  exit  (the  program  being  killed)  at  a 
requirements  review  step.  There  are  231  different  processes  depicted,  each  with  a  stochastic  outcome. 
There  are  192  decision  points  with  probabilistic  outcomes.  There  are  14  batching  processes  to  combine 
flows  from  the  21  splitting  functions.  There  are  over  100  different  information  notations  that  assign 
variables,  keep  track  of  process  information,  or  other  items.  There  are  12  functions  that  stop  further 
processing  along  a  particular  process  path  until  another  condition  is  met  elsewhere  in  the  model.  These 
are  useful,  for  example,  to  depict  if  something  in  the  requirements  process  has  to  wait  for  another 
activity  in  the  acquisition  swim  lane  to  be  completed.  A  detailed  description  of  the  model  appears  in 
Appendix  E. 

Model  Assumptions 

The  unit  of  analysis  within  the  model  is  the  individual  program.  Interaction  effects  or  portfolio 
effects  from  other  programs  are  not  explicitly  modeled  but  are  tacitly  taken  into  account  by  the 
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stochastic  behavior  of  all  of  the  processes  and  probabilistic  nature  of  decisions  throughout  the  model. 


These  items  were  already  mentally  "taken  into  account"  by  the  individuals  whose  reported  process 
distribution  data  and  decision  point  probabilities  form  the  basis  of  the  data  in  the  model.  These 
interdependencies  were  identified  throughout  the  interviews  as  extremely  important  but  also  deemed 
to  be  nearly  impossible  to  quantify. 

Cost,  schedule,  and  ACAT  level  are  the  individual  attributes  associated  with  the  unit  of  analysis 
within  the  model.  Other  attributes  not  chosen  were  Technology  Readiness  Levels  and/or  the  novelty  of 
a  given  program.  These  can  be  considered  for  future  work. 

Further  assumptions  associated  with  the  model  are  that  overall  program  costs  and  schedules 
will  either  remain  the  same  or  increase-despite  the  very  real  possibility  of  a  funding  cut  or  schedule 
reduction.  This  approach  is  rational  as  a  short-term  decision  on  a  given  program  may  reduce  costs 
and/or  schedules  at  first,  but  the  likelihood  of  requirements  relief,  which  is  an  extremely  rare  event, 
remains  minimal,  and  those  requirements  will  need  to  be  met  at  a  later  time,  increasing  the  overall 
program  development  costs  and  schedule. 

Uncertainty  driven  by  political  circumstances  is  artificially  modeled  by  randomly  generating  a 
"program  review"  where  the  finances,  program  management,  and  other  aspects  of  a  program  are 
"reviewed"  for  potential  cuts  and/or  changes.  A  set  driver  of  uncertainty,  also  artificially  driven,  is 
named  simply  "event  happens"  and  is  used  to  account  for  the  stochastic  nature  of  problems 
encountered  in  the  execution  of  the  development  program,  running  the  gamut  from  the  impacts  of 
"known  unknowns"  to  "unknown  unknowns." 

Conclusions 

The  model  of  the  overall  acquisition  system  is  based  on  actual  practice  and  demonstrated 
activity.  The  model  also  tacitly  accounts  for  portfolio  "interdependencies"-a  problem  identified  in  all 
interviews  but  deemed  impossible  to  quantify.  Furthermore,  the  model  reflects  "things  as  they  really 
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are/'  not  just  the  theoretical  operation  of  the  entire  system.  Finally,  the  model  is  robust  enough  that  it 


can  be  programmed  and  will  lend  itself  to  simulation  exercises,  such  as  Monte  Carlo  simulation, 
hypotheses  testing  and  sensitivity  analyses. 

The  development  of  this  model  is  important  to  gain  a  better  understanding  of  the  whole  system. 
It  addresses  the  concerns  of  other  studies  that  have  indicated  only  smaller  portions  of  the  acquisition 
system  have  been  studied  and  whose  recommendations  often  were  ignored  or  unsuccessful.  Currently, 
the  author  is  aware  of  no  other  model  that  exists  on  this  scale  or  scope.  Since  it  may  require  decades  to 
transit  the  existing  process  from  beginning  to  end,  and  the  process  is  constantly  being  changed  and 
adapted,  there  is  great  difficulty  conducting  longitudinal  analyses  that  reflect  the  actual  state  of  the 
system  at  any  given  time.  The  following  chapters  will  demonstrate  how  the  model  was  verified  and 
validated,  along  with  testing  various  hypotheses  to  see  how  development  program  outcomes  can  be 
improved. 
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CHAPTER  6  -  VERIFICATION  AND  VALIDATION 


A  model  of  this  size  and  complexity  encounters  concerns  about  verification  and  validation. 
Verification  is  the  idea  that  the  model  operates  correctly  and  validation  is  the  idea  that  the  model 
correctly  mimics  the  reality  it  is  trying  to  represent.  Both  of  these  concerns  will  be  addressed  in  this 
chapter.  Nevertheless,  it  is  important  to  remember  that  it  is  nearly  impossible  to  verify  a  model  of  a 
complex  system  completely,  but  it  is  also  important  to  obtain  a  degree  of  confidence  in  the  model,  its 
behavior,  and  its  outcomes. 

This  chapter  discusses  how  the  model  was  both  verified  and  validated.  There  are  some  unique 
features  to  this  research  worth  noting.  In  some  sense,  two  different  models  were  both  verified  and 
validated,  strengthening  the  overall  confidence  in  the  final  model  form.  The  first  model  to  go  through 
this  process  was  the  original  model  of  the  system  done  in  a  free-hand  style.  The  second  model  to  go 
through  this  process  was  the  actual  programming  of  the  model  in  a  setting  that  allowed  for  large-scale 
simulation.  These  will  be  elaborated  upon  further  below,  but  the  verification  and  validation  done  on 
each  of  these  models  constitutes  a  strong  effort  to  verify  and  validate  the  larger  model  used  in  this 
research. 

Verification  of  free  style  model 

The  task  to  ensure  the  model  behaves  the  way  it  was  intended  was  approached  very 
methodically.  As  in  the  previous  chapter,  the  initial  forms  of  the  model  were  drawn  freehand  in  the 
program  Dia.  This  program  allowed  for  quick  manipulation  and  easy  navigation  around  the  model.  At 
the  same  time  the  model  was  being  drawn  free-hand,  the  model  was  also  being  documented.  The 
documentation  provided  a  great  deal  of  information  that  could  not  be  represented  in  the  free-hand 
model  drawing.  For  instance,  the  source  of  the  information  and  the  actual  values  for  each  of  these  data 
points  was  consolidated  in  this  documentation.  A  great  deal  of  time  was  spent  combing  through  the 
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interview  data  as  well  as  making  call-backs  and  searching  for  other  official  documentation  to 
substantiate  all  of  the  entries  in  the  model. 

During  the  process  of  drawing  the  model  and  documenting  it,  many  of  the  implicit  connections 
and  underlying  assumptions  that  had  been  carried  by  the  author  were  made  explicit.  Several  weeks  of 
iterations  were  required  to  flesh  out  all  of  the  assumptions. 

Hand  Modeling 

Following  this  phase,  an  intensive  period  of  working  the  system  by  hand  was  accomplished  to 
test  the  logic  and  basic  outcomes.  Since  the  model  was  put  together  using  only  probabilities  and 
random  triangular  distributions;  it  lent  itself  well  to  working  the  model  by  hand  using  a  sheet  of  paper 
and  one  die.  In  some  sense,  checking  the  model  by  hand  seemed  tedious,  but  the  exercise  was  fruitful 
as  additional  logic  errors  were  found  and  other  important  insights  were  gained. 


Hand  model  #1 

Hand  model  #2 

Hand  model  #3 

Hand  model  #4 

Ending  point 

Stay  in 

Sustainment 

system 

Stay  in 

sustainment 

system 

Stay  in 

sustainment 

system 

Milestone  A 

Number  of 

process  steps 

7 

7 

7 

192 

Final  days 

439 

959 

785 

1222 

Table  9:  Example  table  of  hand  modeling  trials 


Regarding  hand  model  #4,  the  exercise  was  terminated  at  Milestone  A  since  the  other  two 
phases  were  similar  in  structure,  with  additional  process  steps,  and  the  same  kinds  of  logic  would  apply. 
However,  one  of  the  most  important  insights  gained  from  this  exercise  was  realizing  a  need  to  keep 
track  of  different  timelines  and  various  variable  states.  The  model  requires  parallel  processing  of 
information  and  process  activities,  e.g.  activities  going  on  at  the  same  time  in  the  different  swim  lanes. 
Without  this  capability,  any  modeling  by  hand  would  quickly  get  lost  in  the  details.  Another  one  of  the 
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key  insights  was  the  explicit  modeling  of  the  PPBE  produced  too  much  variation  in  outcomes,  e.g.  far  too 


many  programs  were  being  "killed"  than  both  the  interviewees  and  personal  experience  suggested  was 
the  case  and  the  process  was  not  ending  within  the  allotted  time,  since  it  is  a  continuous  process  and 
must  keep  its  rhythm.  At  the  rate  at  which  the  hand  modeling  was  going,  no  program  would  ever  make 
it  to  any  milestone  simply  due  to  the  PPBE  modeling. 

After  a  period  of  reflection,  some  of  the  different  interviewee  insights  came  to  mind.  The  PPBE 
was  a  continuous  process  and  was  calendar-driven.  The  other  processes  were  discrete  and  event- 
driven.  Was  it  possible  the  impacts  of  the  PPBE  were  already  accounted  for  elsewhere  in  the  model? 
After  much  thought,  an  answer  emerged:  the  other  process  distributions  likely  already  accounted  for 
the  probabilities  of  whatever  might  by  induced  by  the  PPBE.  It  was  manifest  in  whatever  heuristic  the 
interviewees  used  to  come  up  with  their  probabilities  and  triangular  distributions.  It  accounted  for  the 
unknowns,  including  those  from  the  PPBE,  within  those  items.  This  realization  simplified  the  model 
significantly.  Now  the  PPBE  processes  swim  lane  could  be  used  to  show  the  explicit  impacts  upon 
individual  programs,  such  as  a  step  to  "check  for  available  funding,"  etc. 

PPBE  modeling 

To  further  probe  this  realization,  the  PPBE,  as  originally  modeled,  was  "validated"  by  hand 
separately.  The  PPBE  alone  was  well-suited  for  such  an  exercise.  It  really  was  a  self-contained  model 
that  occasionally  interacted  with  the  other  swim  lanes-specifically  the  acquisition  swim  lane. 


Hand  model 

Hand  model 

Hand  model 

Hand  model 

Hand  model 

#1 

#2 

#3 

#4 

#5 

Process  steps 
required 

46 

48 

14 

7 

279 

Days  elapsed 

757 

757 

350 

64 

5477 

Table  10:  Explicit  PPBE  hand-modeling 
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The  modeling  of  the  PPBE  by  hand  mirrored  both  the  practical  experience  by  the  author  as  well 
as  that  reported  by  the  various  interviewees.  For  example,  some  of  these  outcomes  were:  many 
decisions  being  revisited;  many  opportunities  for  new  items  to  be  inserted  into  the  system;  many 
opportunities,  greater  than  10  touch  points,  where  program  budgets  could  be  manipulated  and/or 
changed.  Nevertheless,  the  direct  impacts  of  these  changes  would  be  seen  only  at  specific  intervals, 
such  as  a  specific  Milestone  decision,  since  nothing  is  really  "firm"  until  the  Budget  is  made  law  and  by 
then,  programs,  by  law,  must  have  funds  "secured"  for  execution  of  contracts  and  other  work.  Changes 
that  were  made  to  budgets  were  not  "real"  until  its  actual  passage  by  Congress  and  Presidential 
signature.  Therefore,  it  was  reasonable  to  "assume"  discrete  events  within  the  PPBE  that  could  be 
associated  with  the  rest  of  the  swim  lanes,  such  as  a  check  for  available  funding.  Any  changes  forced 
upon  a  program  due  to  budget  problems  would  be  manifested  in  the  program  review  cycles  already 
built  into  the  model.  The  most  impact  the  PPBE  had  on  individual  programs  was  expressed  in  the  very 
early  phases  of  the  program  lifecycle-if  you  didn't  have  a  budget  line  item  established,  your  likelihood 
of  being  stopped  was  extremely  high.  However,  this  was  also  manifest  in  the  requirements  swim  lane- 
and  was  easier  to  follow  than  the  PPBE. 

Validation  of  free  style  model 

Upon  completion  of  the  hand  modeling  and  model  documentation,  a  large  printout  of  the 
model  was  created.  The  model  required  nearly  20  feet  of  paper  to  print  in  a  legible  (readable)  format 
on  poster  size  paper.  This  printout  of  the  model  was  then  taken  to  representatives  of  the  Requirements, 
PPBE,  and  Acquisition  swim  lanes  for  their  review  and  feedback.  The  model  documentation  was  part  of 
the  discussion  with  these  individuals,  along  with  the  results  of  the  hand  modeling.  In  addition,  specially 
prepared  papers  were  brought  to  allow  reviewers  to  add  detail  to,  modify,  or  clarify  model 
representations.  The  special  preparations  consisted  of  putting  together  a  specific  format  so  that  the 
feedback  would  be  consistent,  as  well  as  easy  to  process.  Of  particular  importance  was  gathering  or 
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validating  the  probabilities  and  time  distributions  gleaned  from  the  previous  interviews  of  the  two 
studies  described  earlier.  Some  of  the  experts  consulted  were  those  that  had  participated  in  earlier 


studies.  However,  many  of  them  were  new  to  the  study  and  provided  a  fresh  perspective  and  candid 
insights.  A  scanned  image  of  one  such  feedback  sheet  is  shown  below. 
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Figure  27:  Example  of  Scanned  image  of  model  feedback  form 

For  instance,  this  figure  asked  for  feedback  on  the  time  needed  to  do  developmental  testing,  as 
a  percentage  of  the  original  contract  length.  The  feedback  shows  there  are  some  differences  between 
different  ACAT  levels,  and,  in  particular,  the  ACAT  II  programs  were  hard  to  estimate.  The  data  for  ACAT 
III  programs  was  subsequently  used  for  the  ACAT  II  programs. 

A  sampling  of  their  comments  included  feedback  such  as:  “That  sounds  about  right."  "This 
needs  to  be  added."  "Where  is  this  [a  particular  task  or  item]  represented  in  your  model?"  "We  can't 
begin  this  task  here  until  this  [another  item  from  another  swim  lane]  is  completed."  Many  of  these 
items  were  not  explicitly  documented  in  the  literature,  but  were  extremely  important  to  the  behavior  of 
the  system.  One  of  the  other  more  important  items  gained  was  learning  how  the  system  treated  ACAT  I, 
II,  and  III  programs.  On  paper,  in  the  official  documentation,  not  much  mention  is  made  about  the  time 
required  to  work  these  different  programs.  However,  practical  experience  suggested  otherwise. 
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Therefore,  a  great  deal  of  time  and  effort  was  made  during  this  trip  to  collect  any  ACAT  data  that  was 


different  or  caused  a  process  to  be  different  in  its  time  distribution  outcomes  or  a  decision  point  to  have 
a  different  set  of  probabilities.  Surprisingly,  there  were  significant  differences  in  many  more  places  than 
realized. 

These  interviewees  were  encouraged  to  write,  scribble,  change,  annotate,  as  they  felt  needed  to 
be  done  on  the  paper  printout  of  the  model,  its  documentation  and  the  other  paper  feedback 
mechanism.  The  following  image  shows  some  of  the  individual  mark-ups  made  on  the  printed  model. 
The  section  of  the  model  shown  is  the  Pre-Milestone  A  Phase. 

Requirements  Swim  Lane 

Budgeting  and  Programming  Swim  Lane 

Acquisition 


Contractors 


Figure  28:  Image  of  marked-up  paper  model 


As  depicted  above,  many  important  areas  of  the  overall  process  had  not  been  represented  or 
correctly  depicted  in  the  original  model-but  enough  information  was  there  that  all  interviewees  were 
able  to  understand  and  follow  the  process  depiction.  In  the  end,  every  swim  lane  would  require 
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changes  to  incorporate  the  feedback.  As  the  changes  made  were  cumulative,  every  person  could  see 


the  contributions  made  by  the  previous  person  and  often  commented  positively  on  the  changes 
suggested.  Follow-up  telephone  calls  were  made  over  the  next  few  days  following  to  make  sure  that  the 
changes  were  understood  and  correctly  incorporated  into  the  model. 

Verification  of  computer  simulation  model 

Upon  the  choice  of  the  research  version  of  Rockwell  Software's  Arena  to  construct  a  more 
explicit  model  and  later  conduct  discrete-event  simulation,  the  model  was  programmed  into  the 
software.  The  software  uses  the  Windows  platform  as  its  operating  system.  All  of  the  changes  and 
feedback  given  to  the  free-style  model  were  accommodated  in  this  representation. 

From  a  coding  perspective,  the  software  has  a  lot  of  error  checking  and  prevention  logic  built 
into  it.  First,  there  is  a  function  that  checks  to  see  that  every  model  item  is  connected  to  something 
else.  It  makes  sure  there  are  no  orphan  processes  or  decision  points  anywhere.  It  checks  to  see  that 
entry  points  and  exit  points  exist,  all  variables  are  properly  defined-including  any  mathematical  or 
logical  formulas--and  other  parameters  are  properly  set. 

The  second  way  that  the  software  ensures  it  can  be  verified  is  that  it  offers  an  animation 
feature.  This  allows  the  programmer  to  watch  a  simulation  as  it  proceeds  to  make  sure  that  the  model 
behaves  appropriately.  This  is  especially  helpful  in  terms  of  a  complex  system  like  this  one.  It  enables 
the  programmer  to  visually  see  where  the  different  parallel  processes  are  in  the  process  execution  and 
can  give  the  programmer  some  assurance  that  the  model  behavior  is  correct. 

The  third  major  way  the  software  assists  with  the  verification  of  the  model  is  by  allowing  a  step 
function  to  occur.  This  allows  the  programmer  to  go  through  the  model  step-by-step  and,  coupled  with 
the  animation  feature,  see  how  the  system  is  behaving.  Temporary  variables  and  transitory  data 
elements  are  available  for  examination  during  verification.  The  programmer  can  also  highlight  specific 
variables,  entities,  tasks,  etc.,  of  interest  for  specific  reporting  or  more  information. 
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All  three  of  these  methods  were  used  to  de-bug  and  verify  the  performance  of  the  model.  Many 


hours  of  work  and  analysis  were  required  during  this  stage  of  the  research.  The  model  was  verified  on  a 
laptop  computer  with  a  1.79  GHz  Intel  Pentium  M  processor  and  1.5  GB  of  RAM,  running  Microsoft 
Windows  XP  Professional  Version  2002  Service  Pack  3.  Every  iteration  requires  2  to  4  seconds  but  slows 
down  significantly  after  50000  iterations,  probably  because  of  the  limitations  of  the  Windows  file 
management  system  and  the  size  of  the  data  files.  The  model  now  runs  without  error  messages  or 
strange  behaviors  through  100,000  iterations.  Finally,  the  software  creates  a  Microsoft  Access  database 
and  also  uses  a  special  database  query  program  to  develop  reports  and  output  indicators— all  of  which 
help  with  debugging. 

Additionally,  the  software  comes  with  specialty  input/output  analyzer  and  multi-scenario 
analysis  software  that  can  be  used  after  a  simulation  run  has  completed.  These  tools  also  allow  the  data 
to  be  converted  into  non-proprietary  formats  for  further  analyses  by  other  tools.  Random  checks  of 
different  iterations  and  their  respective  outcomes  did  not  turn  up  any  unusual  behaviors.  At  this  point, 
the  model  was  considered  to  be  verified. 

Validation  of  computer  model 

It  is  important  for  the  model  to  have  both  internal  and  external  validity-evidence  to  support  the 
relationship  "between  or  among  its  variables"  and  if  said  relationship  generalizes  beyond  the  specific 
domain  application  of  this  study-for  any  understanding  of  causal  relationships  [121].  At  first  glance, 
one  could  argue  the  model  has  face  validity.  The  outcome  measures  ring  true  to  the  author's  practical 
experience.  The  many  experts  consulted  for  the  model  and,  that  provided  feedback,  expressed  support 
of  its  underlying  structure  and  outcomes.  Notwithstanding  all  of  this,  a  significant  effort  has  been  made 
to  gather  and  obtain  outcome  measures  of  the  real  world  system  in  a  number  of  cases.  The  cases  were 
chosen  at  random  and  are  representative  of  the  overall  system  behavior. 
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The  data  sources  are  varied.  They  range  from  open  source  literature  to  internal  USAF  or  DOD 


databases.  A  list  of  these  sources  follows: 


•  SMART  (System  Metric  and  Reporting  Tool)  data 
access 

-  MAR  (Monthly  Acquisition  Report)  scores  (all  programs  of  record; 
some  since  1990s) 

-  PoPS  (Probability  of  Program  Success)  scores  (all  programs  of 
record  since  2006) 

•  DAMIR  (Defense  Acquisition  Management 
Information  Retrieval)  data  access 

-  SAR  (Selected  Acquisition  Report)  data  (archives;  current; 
preliminary);  APBs  (Acquisition  Program  Baseline),  etc 

•  SACOM  data  access 

-  Acquisition  manning  data  (requested/desired  and  allocated) 

•  AF  Systems  Library  access 

-  PEO  system  groupings;  ACAT  levels  for  programs;  PMs;  locations 

•  OSD  Acquisition  Management  data  access 

-  All  PMDs  (Program  Management  Directive)  since  1989 

•  AF  Financial  data  access 

-  PEM  assignments;  PE  to  program  mapping;  P  &  R  (Planning  & 
Requirements)  documents,  AF  budget  submissions,  archives,  etc. 


Figure  29:  Data  Sources  for  Model  Validation 

Various  GAO  reports  indicate  that  Acquisition  Programs  are  on  average  more  than  two  years 
behind  schedule  and  several  billion  dollars  over  budget,  among  other  things  [1],  Rather  than  rely  upon 
the  GAO  report  for  the  data  to  validate  the  model's  outcomes,  a  separate,  independent  look  at  these 
data  sources  for  specific  and  actual  program  data  was  completed.  With  the  assistance  of  an  Air  Force 
officer  who  just  completed  his  Masters  degree  at  the  Air  Force  Institute  of  Technology,  a  process  of 
tabulating  open-source,  Air  Force,  and  Government  information  regarding  program  performance  in 
terms  of  cost  and  schedule  of  multiple  programs  at  various  ACAT  Levels  was  conducted.  Over  a  three 
week  period,  the  above  named  sources  were  combed  for  information  relating  to  outcome  measures  of 
acquisition  programs.  The  goal  was  to  obtain  outcome  measures  for  at  least  three  and  preferably  five  or 
more  acquisition  programs  per  ACAT  level. 
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Many  of  the  data  sources  are  only  available  from  within  the  .mil  computer  domain  network. 

The  ACAT  list  on  the  Air  Force  Systems  Information  Library50  was  used  to  determine  which  programs  to 
search  for.  This  site  lists  all  of  the  Air  Force  ACAT  I,  II,  and  III  programs/projects.  PMDs  (Program 
Management  Directive)  and  ADMs51  (Acquisition  Data  Memorandum)  were  examined,  but  these  didn't 
provide  much  information  of  use  in  finding  outcome  measures.  PMDs  refer  to  total  programs,  e.g.  B-2, 
and  not  to  specific  projects,  e.g.  B-2  RMP,  and  were  therefore  less  helpful.  There  were  typically  only  a 
few  ADMs  for  each  project,  and  these  focused  more  on  general  program  management  issues.  However, 
in  some  cases,  information  from  these  documents  was  used  to  cross-reference  data  found  in  SMART52 
(System  Metric  and  Reporting  Tool).  While  the  Air  Force  budget53  and  SARs54  were  a  primary  data 
source,  the  cost  data  residing  in  SMART  was  used  because  they  appeared  to  be  the  most  up  to  date  and 
agreed  most  with  other  reported  data. 

In  the  course  of  this  exercise,  every  single  system  listed  on  the  AF  Systems  List  was  examined. 
There  are  164  programs  of  record  as  of  December  30,  2008.  39  of  these  programs  are  of  the  ACAT  I 
variety.  23  programs  are  ACAT  Level  II.  102  programs  are  ACAT  level  III.  There  is  no  accurate  count  of 
the  number  of  non-ACAT  programs,  but  it  is  likely  in  the  thousands.  Among  the  ACAT  II  and  III  programs, 
many  had  no  MAR  reports  available  or  had  been  recently  updated.  This  reason  alone  eliminated  most 
of  these  programs  from  our  sampling  effort. 


https://pml.wpafb.af.mil/Default.asp?consent=89 

https://extranet.acq.osd.mil/dab/adm/index.html 

https://www.my.af.mil/smart/SMART_APP/ 

http://www.saffm.hq.af.mil/budget/ 

http://www.acq.osd.mil/ara/am/sar/ 
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ACAT  I  Programs 

For  active  ACAT  I  programs,  DAMIR55  and  SMART  were  used  for  the  majority  of  the  data 
collected.  For  inactive  programs,  or  those  no  longer  in  active  development,  DAMIR  would  have  the 
program  listed  but  no  information  available;  consequently,  the  results  of  this  examination  do  not 
contain  any  "inactive"  programs.  DAMIR  typically  has  six  different  data  sources  to  pull  information 
from.  These  include  DAES  (Defense  Acquisition  Executive  System)/Web  Services,  SAR,  APB,  SAR 
Baseline,  POM,  and  BES.  Interestingly,  each  of  these  data  sources  often  provided  different  dollar 
figures,  schedule  data,  etc.  The  DAES/Web  Sources  data  source  produces  a  "Current  Status  Report." 

This  is  a  very  detailed  report  that  pulls  its  data  from  the  Acquisition  Program  Baseline  (APB).  The  APBs 
are  helpful  because  they  show  schedule  and  cost  history.  However,  it  is  important  to  note  that  the  APBs 
are  a  "snapshot  in  time"  and  are  typically  issued  only  upon  the  completion  of  a  milestone  or  significant 
program  change.  Therefore,  the  most  recent  APB  can  sometimes  be  several  years  old,  and  it  is  difficult 
to  determine  if  this  new  APB  constitutes  a  baseline  "reset."  Despite  this,  the  numbers  and  dates 
reported  in  SMART  tend  to  agree  with  the  most  recent  APB. 

ACAT  ll/lll  Programs 

SMART  is  the  only  database  that  reports  data  for  ACAT  II  and  ACAT  III  programs.  The  mandate 
to  use  SMART  to  report  on  all  ACAT  programs  was  recently  implemented  in  the  mid-2000s,  according  to 
the  first  study's  interviewees.  The  GAO,  DAMIR  and  the  SARs  only  report  on  MDAPs  (Major  Defense 
Acquisition  Programs)-which  are  ACAT  ones.  While  each  program  from  the  ACAT  List  had  a  page  in 
SMART,  the  data  for  ACAT  II  and  III  programs  was  spotty.  Most  of  the  workspaces  were  not  used  and 
the  data  was  not  always  up  to  date.  Few  of  the  programs  reported  Milestone  B  or  Milestone  C  dates,  so 
this  limited  what  programs  could  be  used  for  validation.  Most  of  the  smaller  programs  worked  from 

55  http://www.acq.osd.mil/damir/ 
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specific  schedule  tasks  instead  of  milestones.  If  reliable  milestone  schedule  information  wasn't  found, 


the  program  was  eliminated  for  consideration,  and  no  attempt  to  track  down  the  cost  data  was  made. 
For  the  programs  that  did  post  MARs,  these  documents  were  very  helpful  for  tracking  schedule  and 
costs.  It  is  important  to  note  that  the  oldest  MAR  available  was  usually  a  couple  years  into  the 
program's  execution,  so  the  first  few  years  of  MARs  were  often  missing.  This  doesn't  mean  these 
programs  never  completed  these  MARs,  it  just  means  they  are  not  stored  in  a  common  repository  and 
this  was  one  of  the  reasons  SMART  was  developed.  Another  problem  with  finding  ACAT  II  and  III  data 
was  that  SMART  only  showed  current  programs.  These  programs  are  typically  shorter  in  duration  than 
ACAT  Is,  so  most  of  the  active  ones  listed  with  data  tend  to  be  early  in  their  development,  Pre-MS  B  and 
earlier,  and  it  could  be  too  early  to  identify  tangible  cost  or  schedule  growth. 

Actual  Data  Results 

The  following  table  shows  the  final  tabulated  results  of  the  sampled  data.  The  data  is 
unfortunately  difficult  to  interpret.  For  instance,  the  percentages  of  cost  variance  and  schedule  variance 
are  tied  to  the  last  baseline  and  the  information  is  taken  from  the  SMART  database  "contract 
performance"  workspace.  Every  time  a  program  is  rebaselined,  a  new  APB  is  issued.  This  changes 
everything  and  becomes  the  new  measuring  stick  by  which  all  things  are  measured.  In  some  respects, 
this  is  understandable,  especially  when  the  scope  of  a  program  changes  dramatically  due  to  changing 
program  end  item  quantities  or  after  a  major  ECP  adds  additional  major  requirements  to  a  program. 

The  negative  side  of  the  rebaselining,  however,  comes  from  using  it  as  a  way  to  cover  or  minimize  other 
problems  encountered.  Where  this  was  done,  the  authors  have  no  way  to  obtain  additional  insight  into 
the  original  cost  and  schedule  data. 

A  short  discussion  explaining  the  dates  listed  in  the  table  below  will  help  the  reader  interpret 
and  understand  the  data.  Dates  were  pulled  from  the  APBs  and  the  SMART  Schedule  workspace.  Often, 
there  was  difficulty  tracking  down  a  program  start  date,  so  the  first  date  reported  was  used  in  these 
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cases.  For  older  programs,  Milestones  I,  II,  and  III  are  reported,  as  a  previous  version  of  DOD  5000  used 


this  nomenclature.  For  the  purposes  of  the  project,  these  milestones  are  similar  in  nature  to  the 
existing  nomenclature  of  milestones  and  therefore  were  treated  as  if  these  were,  respectively, 
Milestones  A,  B,  and  C.  If  the  actual  completion  date  was  still  in  the  future,  the  projection  was  entered 
into  the  database's  actual  completion  date  cell  and  italicized.  Among  the  impressions  about  the  data  is 
that  some  of  the  schedule  dates  reported  in  SMART,  especially  the  older  ones,  were  entered  just  to 
match  the  estimated  dates.  Anytime  an  "actual"  date  reportedly  happened  on  the  first  of  the  month, 
suspicions  were  raised  about  the  quality  of  the  data.  What  real  life  event  always  falls  exactly  on  the  first 
of  the  month? 

The  cost  and  schedule  variance  data  listed  in  the  table  are  taken  directly  from  the  SAR  report 
information  about  that  program.  However,  this  data  is  only  included  to  show  how  easily  misleading  the 
data  can  be.  The  reference  point  from  which  the  cost  and  schedule  variance  is  measured  is  the  most 
recent  APB;  therefore,  it  does  not  measure  total  cost  and  schedule  variance  over  the  life  of  the  program. 
Again,  to  be  fair,  the  most  current  APB  reflects  the  current  state  of  the  acquisition  effort,  including 
whatever  changes  to  scope,  quantity  and  other  items  have  been  agreed  to  by  industry  and  the 
government.  Acquisition  managers  would  like  to  be  evaluated  upon  program  performance  from  the 
most  recent  APB,  not  from  the  total  program  costs  and  estimates  made  long  before  they  ever  became 
involved  with  a  program. 

Some  additional  discussion  about  the  cost  data  listed  will  help  the  reader  better  understand  the 
tabulated  data.  Costs  are  reported  in  then-year  millions  of  dollars.  Total  Acquisition  Cost  is  represented 
as  a  sum  of  RDT&E,  procurement  costs,  and  also  includes  MILCON  costs  when  reported.  Projected  total 
costs  are  referenced  from  the  APBs.  Unfortunately,  it  is  not  known  if  the  APBs  were  released  in 
conjunction  with  a  milestone  event  or  at  some  other  time,  such  as  a  mandatory  "reset"  after  a  Nunn- 
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McCurdy56  breach.  But  data  from  all  available  past  APBs  is  listed  and  this  will  give  some  idea  of  the 
overall  program  growth  from  Milestone  B,  the  official  program  "start,"  to  the  current  APB  date.  Actual 
total  costs  were  pulled  from  the  SMART  cost  workspace  because  SMART  purports  to  have  the  most  up- 
to-date  numbers  that  the  Air  Force  reports  in  budgets,  etc.  Caution  must  be  exercised  when  highlighting 
programs  where  total  costs  have  been  reduced.  Often  times,  the  services  have  simply  decided  to 
reduce  the  quantity  being  bought.  Such  a  program  change  often  masks  the  cost  growth  that  has 
actually  occurred  on  a  program.  For  this  reason,  the  acquisition  unit  cost  data  and  procurement  unit 
cost  data  is  also  included.  For  example,  if  total  purchase  quantities  were  reduced,  the  unit  cost  data 
should  reflect  significant  increases.  What  is  difficult  to  ascertain  is  how  much  of  that  increase  can  be 
attributed  to  other  cost  growth.  The  program  acquisition  unit  cost  and  average  procurement  unit  costs 
were  pulled  from  the  APBs.  For  unit  costs,  Milestone  A  was  pulled  from  the  first  concept  APB.  The  first 
developmental  APB  provided  data  for  Milestone  B,  and  for  Milestone  C  the  unit  costs  were  reported  in 
the  first  production  APB. 

There  were  no  APBs  for  ACAT  II  and  III  programs  and  they  never  seemed  to  use  the  cost 
workspace  in  SMART.  Therefore,  the  BAC  (Budget  at  Completion)  workspace  on  the  MARs  was  used  to 
determine  projected  and  actual  costs.  The  projected  cost  was  taken  from  the  oldest  MAR  available  in 
SMART,  even  though  this,  in  most  cases,  is  not  the  oldest  MAR.  It  cannot  be  guaranteed  that  these  are 
the  original  BACs  for  the  program  for  the  reasons  previously  explained,  but  they  are  the  best  available 
information.  The  actual  costs  were  pulled  from  the  BAC  on  the  most  recent  MARs,  typically  March  2009. 


Named  after  the  sponsoring  legislators,  this  law  established  mandatory  cost  and  schedule  overrun  thresholds 
that  require  a  thorough  examination,  reevaluation  and  justification  of  acquisition  programs.  A  program  that 
breaches  these  thresholds  is  in  jeopardy  of  cancellation  or  a  serious  reduction  of  Congressional  support. 
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Program  Name 

Initial 

ACAT 

Level 

Initial  Start 

Date 

Initial 

Milestone  of 

Entry 

Projected  Milestone  Dates 

Actual  Milestone  Dates 

Initial  Analysis  of  Schedule 

Source 

A 

B 

C 

Source 

A 

B 

C 

Source 

Projected  B 
toC 

Actual  B  to 

C 

%  change 

B-2  RMP 

i 

17  Aug  2004 

SMART 

Schedule 

B 

Jul  2004,  Sep 
2004 

Feb  2007,  Sep 
2008 

Jan  2009 

APB 

17  Aug 
2004 

4  Sep 
2008 

SMART 

Schedule 

30  months 

49  months 

63% 

C-5  RERP 

1  Feb  2000 

SMART 

Schedule 

B 

Nov  2001 

Dec  2006, 
Mar  2007, 

Mar  2008 

Jun  2008 

APB 

5  Nov 

2001 

25  Mar  08 

SMART 

Schedule 

61  months 

88  months 

44% 

JDAM 

11  Sep  2000 

SMART 

Schedule 

A 

Oct  1993 

Oct  1995,  Sep 
1995 

Jul  1999,  Apr 

1998,  Feb 

1999,  Nov 
1999,  Nov 

2000 

Oct  2002 

APB 

1  Oct 

1993 

1  Sep 
1995 

1  Mar 

2001 

SMART 

Schedule 

34  months 

66  months 

94% 

F-22 

1  Oct  1986 

SMART 

Schedule 

A 

Oct  1986 

Jun  1991 

Dec  1999,  Jul 

2001,  Mar 

2002,  Sep 

2002,  Jul 

2003,  Mar 

2004,  Sep 
2004 

May  2007 
APB 

1  Oct 

1986 

lJun  1991 

1  Mar 

2005 

SMART 

Schedule 

102 

months 

165 

months 

62% 

JPATS 

1  Jan  1993 

SMART 

Schedule 

A 

Jan  1993 

Jun  1994,  Feb 
1995,  Aug 
1995 

Jun  1998,  Jan 
1999,  Sep 
1999,  Dec 

1999,  Nov 

2000,  Nov 
2001 

Sep  2007 
APB 

1  Jan 

1993 

1  Aug 
1995 

1  Nov 

2001 

SMART 

Schedule 

34  months 

75  months 

121% 

AMRAAM 

1  Nov  1978 

SMART 

Schedule 

A 

Nov  1978 

Nov  1982,  Sep 
1982 

Jun  1987 

May  2008 

APB 

1  Nov 

1978 

1  Sep 
1982 

1  Jun 

1987 

SMART 

Schedule 

45  months 

45  months 

0% 

B-2  EHF  Increment  1 

22  Feb  2007 

SMART 

Schedule 

B 

Feb  2007 

Jul  2011 

May  2007 

APB 

22  Feb 

2007 

31  Jul 

2011 

SMART 

Schedule 

52  months 

52  months 

0% 

C-130  AMP 

1  Nov  2005 

SMART 

Schedule 

B 

Jul 2007 

Jun  2008 

Feb  2008 

APB 

31  Jul 

2007 

30  Jun 

2009 

SMART 

Schedule 

11  months 

23  months 

109% 

C-17A 

1  Aug  1981 

SMART 

Schedule 

A 

N/A 

Feb  1985,  Nov 
1987 

Dec  1988,  Jan 
1989 

Mar  2005 

APB 

N/A 

1  Nov 

1987 

1  Jan 

1989 

SMART 

Schedule 

13  months 

14  months 

8% 

C-5  AMP 

1  Jan  1999 

SMART 

Schedule 

B 

Jan  1999 

Feb  2003 

Aug  2007 

APB 

1  Jan  1999 

1  Feb 

2003 

SMART 

Schedule 

49  months 

49  months 

0% 

JASSM 

20  Sep  1995 

SMART 

Schedule 

A 

Jun  1996 

Jun  1998,  Nov 

1998 

Apr  2001,  Jul 
2002,  Oct 

2003 

Jul  2004 

APB 

13  Jun 

1996 

09  Nov 

1998 

25  Feb 

2004 

SMART 

Schedule 

29  months 

63  months 

117% 

SDB  1 

1  Oct  2003 

SMART 

Schedule 

A 

Aug  2001 

Oct  2003 

Apr  2005 

Apr  2005 

APB 

1  Aug 

2001 

1  Oct  2003 

29  Apr 
2005 

SMART 

Schedule 

18  months 

18  months 

0% 

B-l  FIDL 

II 

12  Dec  2003 

SMART 

Schedule 

B 

Apr  2005 

Jul  08 

SMART 

Schedule 

16  May 
2005 

29  May 
2009 

SMART 

Schedule 

38  months 

48  months 

26% 

B-52  CONECT 

II 

1  Sep  2003 

SMART 

Schedule 

B 

Feb  2004 

Dec  2008 

SMART 

Schedule 

6  Jul  2004 

23  Dec 

2009 

SMART 

Schedule 

42  months 

66  months 

57% 

IBS 

II 

2  May  2001 

SMART 

Schedule 

B 

May  2001 

Jun  2006 

SMART 

Schedule 

2  May 
2001 

20  Jun 

2006 

SMART 

Schedule 

61  months 

61  months 

0% 

F-15  APG-63(V)3 

II 

16  Sep  2008 

SMART 

Schedule 

C 

Mar  2009 

SMART 

Schedule 

31  Mar 

2010 

SMART 

Schedule 

6  months 

18  months 

200% 

B-l  VSD  Upgrade 

III 

8  Mar  2006 

SMART 

Schedule 

B 

Mar  2006 

Feb  2009 

SMART 

Schedule 

8  Mar 

2006 

15  Jul 

2009 

SMART 

Schedule 

35  months 

40  months 

14% 

B-l  INS  Replacement 

III 

29  Nov  2007 

SMART 

Schedule 

B 

Nov  2007 

May  2010 

SMART 

Schedule 

29  Nov 

2007 

1  Oct 

2010 

SMART 

Schedule 

30  months 

35  months 

17% 

JICO  Support  System  (JSS) 

III 

13  Aug  2004 

SMART 

Schedule 

B 

Aug  2004 

Mar  2009 

SMART 

Schedule 

13  Aug 
2004 

31  Sep 
2009 

SMART 

Schedule 

55  months 

61  months 

11% 

Combat  Key  Generator  (KOK-13) 

III 

14  Oct  2005 

SMART 

Schedule 

B 

Jan  2007 

Sep  2009 

SMART 

Schedule 

17  Jun 

2007 

15  Jul 

2009 

SMART 

Schedule 

27  months 

25  months 

-7% 

Table  11:  Multi-source  Acquisition  Program  Schedule  Data 


132 


Program  Name 

Prog  Acq  Unit  Cost  ($M)  at 
Beginning  of  Milestone 

Avg  Proc  Unit  Cost  ($M)  at  Beginning  of 
Milestone 

Projected  Total 
Acquisition  Cost 
($M) 

Actual  Total 
Acquisition 
Cost  ($M) 

%  Cost 

Variance 

(Then-Yr) 

% 

Schedule 

Variance 

A 

B 

C 

Most 

Recent 

Source 

A 

B 

C 

Most 

Recent 

Source 

Source 

Source 

Source 

Source 

B-2  RMP 

58.095 

67.420 

67.420 

Jan  2009 

APB 

39.150 

48.408 

48.408 

Jan  2009 

APB 

1220, 1348.4 

Jan  2009 

APB 

1348.4 

SMART 

Cost 

0.4 

Sep  08 

SAR 

-1.0 

Dec  07 

SAR 

C-5  RERP 

88.047 

147.963 

147.963 

Jun  2008 

APB 

78.293 

123.308 

123.308 

Jun  2008 

APB 

11093.9, 
10020.6, 
11004.2,  7694.1 

Jun  2008 

APB 

7667.9 

SMART 

Cost 

7.6 

Sep  08 

SAR 

-5.5 

Jun  08 

SAR 

JDAM 

0.070 

0.038 

0.029 

0.025 

Oct  2002 

APB 

0.056 

0.033 

0.024 

0.023 

Oct  2002 

APB 

5240.3,  3392.3, 
2606.7,  5630.8 

Oct  2002 

APB 

5473.0 

SMART 

Cost 

29.6 

Sep  08 
SAR 

N/A 

N/A 

F-22 

152.946 

338.805 

339.768 

May  2007 

APB 

122.333 

186.933 

186.933 

May  2007 

APB 

3282.0,  99109.0, 
72364.9, 

64340.1, 

65933.2, 
61760.8, 

68833.3, 

71785.3, 
61323.7, 
61498.0 

2007  APB 

64016.2 

SMART 

Cost 

4.6 

Sep  08 

SAR 

N/A 

N/A 

JPATS 

9.596 

5.689 

6.438 

7.230 

Sep  2007 
APB 

9.108 

5.068 

6.009 

6.700 

Sep  2007 
APB 

6658.0,  4050.6, 
3997.0,  4555.8, 
5041.1,  5552.8 

Sep  2007 

APB 

5515.0 

SMART 

Cost 

11.5 

Sep  08 

SAR 

N/A 

N/A 

AMRAAM 

0.484 

0.460 

0.849 

1.141 

May  2008 

APB 

0.430 

0.413 

0.761 

1.002 

May  2008 

APB 

8340.2, 11199.2, 

11592.4, 

13112.4, 
13327.9, 
19417.3 

May 

2008  APB 

21477.7 

SMART 

Cost 

30.9 

Sep  08 

SAR 

-3.8 

Dec  07 

SAR 

B-2  EHF  Increment  1 

33.624 

N/A 

33.624 

May  2007 

APB 

7.747 

N/A 

7.747 

May  2007 

APB 

706.1 

2007  APB 

550.0 

SMART 

Cost 

-3.6 

Sep  08 

SAR 

-1.4 

Dec  07 

SAR 

C-130  AMP 

7.640 

N/A 

26.622 

Feb  2008 

APB 

6.538 

N/A 

18.186 

Feb  2008 

APB 

3965.4,  4574.2, 
4865.9,  5910.1 

Feb  2008 

APB 

5783.0 

SMART 

Cost 

102.8 

Sep  08 

SAR 

-14.6 

Dec  07 

SAR 

C-17A 

N/A 

178.355 

199.104 

326.074 

Mar  2005 

APB 

N/A 

151.369 

171.871 

279.581 

Mar  2005 

APB 

37454.6, 
41811.9, 
34802.0, 
22476.4, 

43261.7, 
45860.6, 

58693.4 

Mar  2005 

APB 

61185.6 

SMART 

Cost 

55.1 

Sep  08 
SAR 

-8.9 

Dec  07 

SAR 

C-5  AMP 

N/A 

14.038 

12.939 

Aug  2007 

APB 

N/A 

12.939 

9.453 

Aug  2007 

APB 

856.3,  1449.2 

Aug  2007 

APB 

1340.2 

SMART 

Cost 

22.4 

Sep  08 

SAR 

N/A 

N/A 

JASSM 

1.242 

0.840 

0.914 

0.914 

Jul  2004 

APB 

0.916 

0.504 

0.702 

0.702 

Jul  2004 

APB 

3034.7,  2073.3, 

3130.8,  3313.6, 

4070.8,  4981.1 

Jul  2004 

APB 

7242.6 

SMART 

Cost 

30.2 

Sep  08 
SAR 

0.2 

Dec  07 

SAR 

SDBI 

N/A 

0.074 

0.074 

0.074 

Apr  2005 
APB 

N/A 

0.059 

0.059 

0.059 

Apr  2005 
APB 

1786.3 

Apr  2005 

APB 

1482.9 

SMART 

Cost 

-17.3 

Sep  08 

SAR 

N/A 

N/A 

B-l  FIDL 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

117.7, 117.8, 
117.9, 117.6, 
117.1, 116.0, 
138.9, 159.4, 
160.3, 160.2, 
162.4 

2006 

MAR 

291.0 

Mar  2009 

MAR 

N/A 

N/A 

N/A 

N/A 

B-52  CONECT 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

195.7 

Oct  2005 

MAR 

195.7 

Mar  2009 

MAR 

N/A 

N/A 

N/A 

N/A 

IBS 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

85.8,  85.4.  85.1, 
86.0,  92.0, 
116.2, 115.5, 
148.8,  149.6 

Jul  2003 

MAR 

151.3 

Mar  2009 

MAR 

N/A 

N/A 

N/A 

N/A 

F-15  APG-63(V)3 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

180.1 

Nov  2008 

MAR 

180.3 

Mar  2009 

MAR 

N/A 

N/A 

N/A 

N/A 

B-l  VSD  Upgrade 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

51.1 

Aug  2008 

MAR 

51.1 

Mar  2009 

MAR 

N/A 

N/A 

N/A 

N/A 

B-l  INS  Replacement 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

62.3 

Aug  2008 

MAR 

62.5 

Mar  2009 

MAR 

N/A 

N/A 

N/A 

N/A 

JICO  Support  System  (JSS) 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

38.7,  45.8,  54.0, 
57.4,  56.2,  57.7, 

57.8,  57.7,  62.6, 
57.7 

Aug  2006 

MAR 

71.4 

Apr  2009 

MAR 

N/A 

N/A 

N/A 

N/A 

Combat  Key  Generator  (KOK-13) 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

7.8,  8.3 

Apr  2008 

MAR 

9.0 

Apr  2009 

MAR 

N/A 

N/A 

N/A 

N/A 

Table  12:  Multi-source  Acquisition  Program  Cost  Data 


A  few  limitations  about  this  data  sampling  effort  need  to  be  noted.  Accessing  the  information 
databases  was  probably  the  biggest  difficulty  during  this  effort.  By  design,  the  information  is  not  widely 
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available.  Even  after  securing  permission  for  read-only  access  to  these  databases,  on  a  few  occasions, 


the  systems  were  too  slow  to  be  usable  or  not  functioning  at  all.  For  example,  many  interviewees 
during  the  first  study  also  commented  on  the  "speed"  or  lack  thereof  of  the  online  management  tools 
and  information  repositories  and  their  personal  frustration  with  these  systems. 

Across  the  many  different  reports  and  databases  available  for  ACAT  I  programs,  there  is  much 
conflicting  data.  A  great  deal  of  time  was  spent  comparing  and  re-checking  the  data  to  determine  which 
figures  where  the  most  accurate.  In  the  end,  the  best  databases  (APBs  and  SMART)  were  subjectively 
selected  because  of  reasons  previously  cited  and  efforts  were  made  to  use  them  exclusively  for  all 
information  on  each  program.  This  decision  was  made  to  mitigate  biases  across  databases.  This  also 
enabled  one  to  compare  the  different  programs  as  reported  from  the  same  database  source. 
Unfortunately,  this  decision  also  eliminated  some  programs  from  consideration  because  sometimes  data 
was  missing  from  these  "better"  databases  too. 

As  mentioned  earlier,  there  is  little  information  on  ACAT  ll/lll  programs.  The  second  page  of  the 
MARs  is  really  the  only  place  where  cost  and  schedule  information  could  be  found,  but  even  then  most 
of  the  ACAT  II  and  III  programs  did  not  provide  such  data. 

The  GAO  uses  DAMIR  as  the  source  of  information  for  its  many  reports  on  the  state  of  the 
acquisition  system  and  the  source  of  DAMIR's  info  appears  to  be  the  SMART  database.  The  recent  GAO 
report  on  Acquisition  gives  a  good  reference  point  for  the  validity  of  the  data  found.  They  reported  that 
in  the  last  year,  95  of  the  Pentagon's  largest  weapons  programs  have  exceeded  their  budgets  by  a 
combined  total  of  $295  Billion  and  are,  on  average,  two  years  behind  schedule  [1],  Therefore,  since 
SMART  appeared  to  be  the  original  source  of  all  of  this  data,  it  was  selected  as  the  best  database  overall 
for  this  data  collection  project.  Because  ACAT  ll/llls  typically  use  schedule  tasks  instead  of  milestones, 
the  contract  performance  tables  on  the  second  page  of  the  Monthly  Acquisition  Reports  (MARs) 
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provided  the  best  way  to  track  cost  variance  (CV)  and  schedule  variance  (SV)  (example  shown  below). 


Unfortunately,  many  of  the  ACAT  Ills  do  not  have  these  charts. 


Contractor:  xxxx  Company  Data  Source:  CPR  EAC  (Ktr):  $291. OM  SPI:  1.00 

Contract  Type:  CPIF  As  Of  Date:  Feb  2009  EAC  (SPO):  $291  .OM 

Figure  30:  Example  Contract  Performance  Tables  as  found  on  Page  2  of  each  MAR 
Charts  like  these  show  a  lot  of  information  that  a  program  manager  is  expected  to  use  in 
managing  a  program.  Visually,  the  data  shown  includes  lagging  measures  designed  to  show  how  a 
contractor  is  spending  its  money  (or  using  its  resources)  according  to  the  plan  and  also  whether  or  not 
the  schedule  is  being  met  according  to  plan.  Any  favorable  variances  are  reflected  with  a  positive 
number;  a  negative  result  is  unfavorable.  For  instance,  Cost  Variance  (CV)  is  the  result  of  the  Budgeted 
Cost  for  Work  Performed  (BCWP),  or  the  value  of  work  accomplished,  minus  the  Actual  Cost  of  Work 
Performed  (ACWP).  Schedule  Variance  (SV)  is  the  BCWP  minus  the  Budged  Cost  for  Work  Scheduled 
(BCWS),  or  the  value  of  work  planned  to  be  done.  Variance  at  Completion  (VAC)  is  the  Budget  at 
Completion  (BAC)  minus  the  Estimate  at  Completion  (EAC).  Cost  efficiency  (CPI)  is  the  ratio  of  BCWP  to 
ACWP.  Schedule  efficiency  (SPI)  is  the  ratio  of  BCWP  to  BCWS.  For  these  efficiencies,  a  favorable  ratio  is 
greater  than  1.0.  An  unfavorable  ratio  is  less  than  1.0.  Variances  and  performance  indices  help  a 
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program  manager  know  where  and  how  to  apply  its  Management  Reserve  (MR)  funds  to  help  the 
program  as  much  as  possible  meet  cost  and  schedule  targets. 

One  of  the  more  interesting  observations  about  the  data  was  that  by  all  appearances,  it  seemed 
only  those  programs  in  "trouble"  were  the  ones  consistently  tracked  or  the  ones  that  seemed  to  have 
the  greatest  variance  shown  in  their  metrics  from  established  baselines.  Further,  in  an  effort  to  avoid 
costs,  it  seemed  that  many  of  the  Earned  Value  Management  requirements  (contract  performance 
metrics)  were  waived  early  in  programs  and  not  required  for  most  ACAT  III  programs.  Usually,  other 
reporting  requirements  were  also  negotiated  away  in  final  contract  discussions  as  a  cost  saving 
measure.  This  may  have  been  prudent  at  the  time  of  the  decision  to  do  so  in  order  to  "save"  money, 
but  it  makes  it  more  difficult  for  researchers  to  obtain  cost  and  schedule  information  and  to  understand 
these  outcome  measures.  It  also  reinforces,  perhaps  incorrectly,  the  notion  to  the  outside  observer  that 
performance  is  the  key  driver  for  all  of  these  systems,  and  therefore,  cost  and  schedule  deviations  are 
not  only  expected,  but  acceptable. 

A  final  concern  about  using  this  program  information  for  validation  purposes  is  that  the  official 
definition  of  a  program  begins  at  Milestone  B-and  the  scope  of  this  model  ends  at  Milestone  C.  Much 
of  the  Pre-Milestone  B  data  appears  to  be  suspect  in  nature,  i.e.  dates  begin  exactly  at  the  start  of  a 
month  and  are  listed  as  happening  exactly  on  time  and  without  delay--which  runs  counter  to  the 
interview  data  collected  across  the  two  different  studies  in  Chapters  3  and  4.  Therefore,  for  validation 
purposes,  the  data  that  will  be  used  for  validation  of  time  elapsed  will  be  existing  data  between 
Milestone  B  and  Milestone  C.  As  the  time  distribution  ranges  take  into  account  scope  changes  and 
various  other  items  of  turbulence,  the  initial  dates  listed  will  be  used  as  the  baseline  to  measure  against 
the  actual  dates. 

Validation  of  cost  data  in  the  model  was  not  done  due  to  the  multiple  methods  of  cost 
accounting  used  that  tend  to  obscure  true  cost  reporting.  As  mentioned  earlier,  the  closest  attempt  at  a 
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fair  way  to  measure  cost  outcome  measures  objectively  occurs  in  the  per  unit  cost  data,  but  even  this 


data  does  not  provide  the  granularity  needed  into  the  reasons  why  unit  costs  changed,  e.g.  change  in 
quantity  ordered  or  other  cost  growth. 

The  model  does  not  calculate  per  unit  costs,  rather  it  contains  mechanisms  to  track  cumulative 
cost  data.  Since  schedules  are  tied  to  costs,  the  schedule  portion  of  the  model  was  assumed  to  be  a 
representative  surrogate  for  program  costs.  Therefore,  reporting  cost  data  from  the  model  was  deemed 
as  redundant  for  this  exploratory  effort.  Modeled  cost  data  will  not  be  reported  or  included  in  this 
work.  Future  work  and  additional  analysis  might  be  able  to  tease  out  actual  cost  data  in  a  way  that 
would  allow  additional  insights  and  comparison  to  the  model,  especially  to  validate  the  cost  data  coming 
out  of  the  model. 

Comparison  of  model  outcomes  and  actual  data  -  Final  Validation 

Statistical  tests  allow  one  to  have  a  level  of  confidence  in  the  data  that  has  been  obtained  and 
also  to  find  if  there  are  valid  relationships  between  data  sets.  In  the  case  of  the  model,  the  output  is 
represented  in  an  elapsed  amount  of  time.  For  the  data  presented  in  this  section,  the  model  went 
through  10,000  iterations  to  build  up  a  proper  sample  size.  Actual  data  was  also  gathered  to  determine 
an  elapsed  amount  of  time  between  acquisition  milestones. 

When  comparing  data,  typically  we  are  encouraged  to  see  if  there  is  any  statistical  relationship 
between  the  data.  In  this  case,  we  have  two  sets  of  data,  one  from  a  computer  simulation  and  the  other 
from  actual  events.  One  represents  the  model's  effort  to  define  the  distribution  of  outcomes  for 
programs  between  Milestone  B  and  Milestone  C.  The  other  represents  actual  data  for  the  same  time 
span.  The  hypothesis  being  tested  is  to  determine  if  the  means  of  the  data  are  the  same  or  different 
from  each  other's.  The  main  assumption  is  that  the  data  are  normally  distributed.  Historically,  the 
student's  t-test  is  recommended  when  there  are  smaller  samples.  However,  Ruxton  suggests  the 
unequal  variance  t-test  is  a  superior  alternative  to  the  student  t-test  and  the  Mann-Whitney  U  test 
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[122],  The  unequal  variance  t-test  will  be  used  to  test  the  hypothesis.  It  involves  the  calculation  of  a  t 


statistic  that  can  be  compared  with  the  appropriate  value  in  standard  t  tables.  This  is  the  representation 
of  this  calculation.  X  is  the  mean  of  the  sample.  S2  is  the  unbiased  estimator  of  the  variance  of  the  two 
samples  and  n  is  the  number  of  the  participants.  The  subscripts  distinguish  the  two  samples  from  each 
other. 


t  = 


X±  -  x2 

SXi-X2 


where 


n2  [123] 


Figure  31:  Unequal  sample-t  test 


All  ACAT  results  vs  all  actual  data 


The  following  diagram  is  a  histogram  of  all  model  data  for  all  ACAT  programs  completing 
Milestone  C  that  had  no  deviations  from  the  "normal"  process,  e.g.  MS  A  to  MS  B  to  MS  C,  etc. 
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Histogram  of  all  ACAT  programs  MS  B  to  MS  C 


Days  elapsed 


□  Frequency 


Figure  32:  Histogram  of  time  elapsed  for  all  ACAT  programs  between  MS  B  and  MS  C 

The  following  figure  shows  the  same  data  for  the  actual  data  discussed  earlier  in  this  chapter. 


Histogram  of  actual  data  -  all  ACATs 


Days 

□  Frequency 


Figure  33:  Histogram  of  actual  program  data  time  elapsed  between  MS  B  and  MS  C 
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The  null  hypothesis  HO  is  that  the  mean  difference  between  the  samples  is  zero.  Using  the  Data 


Analysis  pack  in  Microsoft  Excel,  the  following  results  were  obtained. 


t-Test:  Two-Sample  Assuming  Unequal  Variances 


Simulated  Data 

Actual  Data 

Mean  (days) 

1888.41 

1620.45 

Variance 

299682.97 

991072.37 

Observations 

2613.00 

20.00 

Hypothesized  Mean  Difference 

0.00 

df 

19.00 

tStat 

1.20 

P(T<=t)  one-tail 

0.12 

t  Critical  one-tail 

1.73 

P(T<=t)  two-tail 

0.24 

t  Critical  two-tail 

2.09 

Table  13:  t-Test:  Two-Sample  test  assuming  unequal  variances  between  data  for  all  ACATs 


Since  the  null  hypothesis  is  that  the  mean  difference  is  zero,  this  is  a  two-sided  test.  Since  the  t- 


statistic  <  t  critical  (1.20  <  2.09)  and  p  value  >  alpha  (0.24  >  0.05),  the  null  hypothesis  is  not  rejected  at 


the  95%  confidence  level. 


ACAT  I  model  results  vs  ACAT  I  actual  results 

Next,  the  ACAT  I  data  will  be  tested.  The  following  diagrams  are  for  both  sets  of  ACAT  I  data 


(model  and  actual). 
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Histogram  of  ACAT  I  only  programs  MS 
B  to  MS  C 
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Figure  34:  Histogram  of  time  elapsed  for  ACAT  I  data  between  MS  B  and  MS  C 


Histogram  of  actual  data  -  ACAT  I 


Days 

□  Frequency 


Figure  35:  Histogram  of  time  elapsed  for  ACAT  I  data  between  MS  B  and  MS  C 
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The  associated  unequal  variances  t-test  reveals  the  following: 


t-Test:  Two-Sample  Assuming  Unequal  Variances 


Simulated  Data 

Actual  Data 

Mean  (days) 

2310.44 

1800.67 

Variance 

275594.31 

1435249.52 

Observations 

657.00 

12.00 

Hypothesized  Mean  Difference 

0.00 

df 

11.00 

tStat 

1.47 

P(T<=t)  one-tail 

0.08 

t  Critical  one-tail 

1.80 

P(T<=t)  two-tail 

0.17 

t  Critical  two-tail 

2.20 

Table  14:  ACAT  I  model  and  actual  data  test  results 


Since  the  null  hypothesis  is  that  the  mean  difference  is  zero,  this  is  a  two-sided  test.  Since  the  t- 


statistic  <  t  critical  (1.47  <  2.20)  and  p  value  >  alpha  (0.17  >  0.05),  the  null  hypothesis  is  not  rejected  at 


the  95%  confidence  level. 


ACAT  II  model  results  vs  ACAT  II  actual  results 

Next,  the  ACAT  II  data  will  be  tested.  The  following  diagrams  are  for  both  sets  of  ACAT  II  data 


(model  and  actual). 
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Histogram  of  ACAT  II  only  MS  B  to  MS  C 


Days 


□  Frequency 


Figure  36:  ACAT  II  model  data  between  MS  B  and  MS  C 


Histogram  of  actual  data  -  ACAT  II 
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□  Frequency 


Figure  37:  ACAT  II  actual  time  elapsed  data  between  MS  B  and  MS  C 

The  associated  unequal  variances  t-test  reveals  the  following: 
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t-Test:  Two-Sample  Assuming  Unequal  Variances 


Simulated  Data 

Actual  Data 

Mean  (days) 

2038.78 

1476.50 

Variance 

185708.13 

422276.33 

Observations 

333.00 

4.00 

Hypothesized  Mean  Difference 

0.00 

df 

3.00 

tStat 

1.73 

P(T<=t)  one-tail 

0.09 

t  Critical  one-tail 

2.35 

P(T<=t)  two-tail 

0.18 

t  Critical  two-tail 

3.18 

Table  15:  ACAT II  model  and  actual  t-test  results 


Since  the  null  hypothesis  is  that  the  mean  difference  is  zero,  this  is  a  two-sided  test.  Since  the  t- 


statistic  <  t  critical  (1.73  <  3.18)  and  p  value  >  alpha  (0.18  >  0.05),  the  null  hypothesis  is  not  rejected  at 


the  95%  confidence  level. 


ACAT  III  model  results  vs  ACAT  III  actual  data  results 


Next,  the  ACAT  III  data  will  be  tested.  The  following  diagrams  are  for  both  sets  of  ACAT  I  data 


(model  and  actual). 
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Histogram  of  ACAT  III  only  MS  B  to  MS  C 
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Figure  38:  ACAT  III  model  histogram  of  time  elapsed  between  MS  B  and  MS  C 


Histogram  of  actual  data  -  ACAT 
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Figure  39:  Flistogram  of  ACAT  III  actual  time  elapsed  between  MS  B  and  MS  C 


145 


The  associated  unequal  variances  t-test  reveals  the  following: 


t-Test:  Two-Sample  Assuming  Unequal  Variances 


Simulated  Data 

Actual  Data 

Mean  (days) 

1686.72 

1223.75 

Variance 

215631.26 

224564.92 

Observations 

1623.00 

4.00 

Hypothesized  Mean  Difference 

0.00 

df 

3.00 

tStat 

1.95 

P(T<=t)  one-tail 

0.07 

t  Critical  one-tail 

2.35 

P(T<=t)  two-tail 

0.15 

t  Critical  two-tail 

3.18 

Table  16:  t-test  results  for  ACAT  III  data 


Since  the  null  hypothesis  is  that  the  mean  difference  is  zero,  this  is  a  two-sided  test.  Since  the  t- 
statistic  <  t  critical  (1.95  <  3.18)  and  p  value  >  alpha  (0.15  >  0.05),  the  null  hypothesis  is  not  rejected  at 
the  95%  confidence  level. 

Across  all  breakdowns  of  data,  there  is  a  high  degree  of  confidence  that  the  mean  difference 
between  the  data  is  zero.  This  analysis  was  also  done  excluding  those  programs  that  had  not  yet 
reached  MS  C  as  of  March  2009.  There  was  no  difference  in  the  outcomes  of  the  statistical  analysis. 
Therefore  the  two  samples  represent  the  same  outcome  of  program  data  between  MS  B  and  MS  C  at  a 
95%  confidence  level. 


Conclusions 

Through  the  careful  verification  and  validation  of  both  the  free-hand  model  and  a  subsequent 
computer  programmed  model,  this  chapter  has  demonstrated  both  models  have  internal  validity.  It 
comes  from  tying  conceptual  evidence  across  the  two  model  forms  to  the  empirical  evidence 
established  by  statistical  testing  of  the  model  output  and  actual  system  data. 

A  great  deal  of  time  and  effort  was  made  to  not  only  sample  system  participants,  but  to  also  go 
to  additional  members  of  the  system  for  feedback  on  the  model  and  its  construct.  The  care  and 
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attention  given  to  representing  the  individual  model  elements  correctly  facilitated  easy  understanding 


among  those  asked  for  feedback.  This  feedback  improved  the  model  tremendously  and  paved  the  way 
for  a  relatively  smooth  coding  effort  into  the  modeling  environment  chosen.  It  also  helped  with  the 
overall  debugging  as  well  as  the  overall  verification  and  validation  of  the  model  results  using  statistical 
means. 

There  is  a  high  degree  of  confidence  that  the  model  not  only  behaves  as  intended  but  also  does 
a  good  job  in  developing  data  consistent  with  actual  acquisition  program  outcomes.  While  only  a 
portion  of  this  model  could  be  tested  empirically,  the  methodology  used  in  constructing  the  model 
remained  the  same  throughout  and  lends  credibility  where  empirical  testing  falls  short. 
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CHAPTER  7-  MODEL  RESULTS  AND  REPRESENTATIVE 
OUTPUT 


As  mentioned  earlier,  the  model  is  designed  to  mimic  the  performance  of  the  large  "enterprise" 
system  of  weapon  system  acquisition  in  the  US  Air  Force.  It  begins  at  the  point  where  new  ideas  are 
being  explored  and  are  entering  the  system  at  a  rapid  pace.  The  system  filters  out  a  great  deal  of  them 
and  only  those  with  a  chance  of  viability  enter  the  formalized  system.  Even  then,  a  majority  of  these 
ideas  are  shuttled  off  toward  an  existing  activity  (another  weapon  system  in  the  sustainment  phase) 
where  the  idea  can  be  added  as  a  modification  to  an  existing  platform  or  platforms.  A  relatively  small 
number  of  programs  actually  enter  the  formalized  system  and  complete  it  through  milestone  C.  The 
model  is  robust  in  that  it  easily  accommodates  the  majority  of  the  paths  and  processes  that  exist  in  the 
overall  system.  Some  of  the  robustness  comes  from  many  of  the  underlying  assumptions  that  exist  in 
the  model  and  the  way  individual  process  tasks  and  decision  points  are  represented. 

Model  Parameters 

The  model  is  coded  within  the  Arena  simulation  software  environment  but  does  not 
automatically  contain  all  of  the  information  needed  to  begin.  The  main  settings  needed  are  to  indicate 
how  many  iterations  of  the  model  the  software  should  complete,  the  time  step  of  interest  (days)  and 
how  many  hours  are  available  per  day  for  use  (24).  The  user  has  the  option  to  determine  what  kinds  of 
statistics  should  be  collected  beyond  the  typical  assortment  of  data  the  model  captures.  Finally,  the 
user  can  determine  the  speed  of  the  animations  (if  they  have  been  turned  on)  as  well  as  the  frame 
refresh  rate  to  display  the  animation.  The  software  automatically  reinitializes  every  variable  at  the 
beginning  of  each  iteration  and  keeps  track  of  the  multiple  activities  going  on  in  parallel  at  any  given 
point  throughout  each  simulation  iteration. 

A  few  assumptions  exist  within  the  model.  They  are  repeated  here  for  convenience.  The  unit  of 
analysis  is  a  program  or  idea.  The  ACAT  level  is  randomly  selected  as  well  as  the  different  paths  a 
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particular  idea  may  follow  as  per  the  expert  data  collected  in  the  previous  interviews.  An  acquisition 


program  is  the  unit  of  analysis;  the  term  project  or  program  is  used  interchangeably;  different  ACAT 
levels  are  generated  randomly  according  to  expert  assisted  determination  of  frequency;  interactions  and 
interdependencies  among  projects  are  captured  in  the  existing  process  time  distributions;  and  that 
there  are  no  'memory  effects'  between  the  processes  and  subsequent  iterations  of  the  model.  The 
memory  effects  assumption  addresses  the  probability  of  interdependencies  in  the  system  (but  not 
necessarily  between  projects).  If  each  program  were  modeled  with  "memory"  -  or  if  actions  taken 
earlier  in  the  lifecycle  change  the  attributes  of  the  program  in  a  way  that  substantially  affects  the  way  it 
is  treated  by  subsequent  processes  -  then  there  would  be  significantly  different  model  outcomes 
possible.  There  would  probably  be  many  information  feed-forward  loops  going  on  to  "prepare"  the 
down  stream  processes  for  the  coming  program  along  with  associated  feedback  loops  for  the  same 
reason.  Arguments  for  or  against  such  a  modeling  construct  could  be  easily  debated  here.  However, 
not  including  this  information  seemed  reasonable  as  it  takes  years  to  go  through  the  process  and  any 
'corporate'  or  'collective'  memory  about  a  program  will  likely  be  forgotten  over  time  due  to,  among 
other  things,  the  turnover  in  personnel,  the  inevitable  changes  in  cost,  schedule  and  requirements.,  etc. 
If  there  is  any  associated  memory  effect,  the  results  of  this  effect  would  likely  change  the  time 
distributions/variance  of  different  processes  as  well  as  change  probabilities  at  different  decision  points. 

Model  Simulation 

Having  the  ability  to  simulate  this  model  allows  a  great  deal  of  analysis  to  take  place.  Powerful 
analysis  techniques  such  as  Monte  Carlo  simulation  and  data  fitting  using  statistical  techniques  allows 
the  researcher  to  cover  a  large  number  of  hypothetical  situations  in  a  very  short  period  of  time. 

10,000  iterations  were  chosen  as  a  good  number  to  test  the  behavior  and  operation  of  the 
model  while  allowing  all  possible  path  combinations  to  be  explored.  Running  a  simulation  of  the  model 
with  10,000  iterations  requires  approximately  one  hour.  This  varies  upon  the  other  demands  on  a 
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computer's  CPU  cycles,  etc.  The  time  required  above  is  with  the  built-in  animation  turned  off.  The 
intent  is  to  assess  if  that  number  is  sufficient  to  characterize  system  behavior  within  acceptable 
variation.  A  discussion  of  the  number  of  iterations  necessary  to  characterize  the  system  will  occur  later. 

In  order  to  understand  the  behavior  of  the  model,  many  places  of  the  model  are  "instrumented" 
to  provide  data  for  further  analysis.  Arena  is  well-suited  for  analysis  of  this  kind  and  enables  relatively 
easy  access  to  points  within  the  model  for  data  collection.  Most  of  the  data  is  collected  automatically  by 
Arena  but  also  allows  for  user-defined  information  to  be  collected.  The  robustness  of  this  simulation 
platform  is  appealing  because  it  is  so  easily  customized.  Some  real  world  information  exists  about  the 
different  process  yields.  There  are  multiple  exit  points  to  the  system  and  not  all  of  them  are  analyzed 
except  for  understanding  the  frequency  of  items  that  met  these  termination  points.  The  following 
graphs  and  tables  represent  typical  model  outputs.  A  brief  explanation  or  summary  of  each  output  will 
follow. 

Typical  model  output 

The  typical  model  output  consists  of  a  raw  text  file  with  the  information  requested.  A  separate 
file  for  each  query  is  generated.  For  instance,  one  of  the  more  important  points  being  evaluated  is  the 
outcomes  at  Milestone  C.  The  data  file  at  this  point  of  the  model  records  the  value  of  the  variable  (time) 
at  Milestone  C  or  if  the  simulation  finishes  along  another  path  (e.g.  the  program  is  killed),  the  value  of 
the  Milestone  C  variable  remains  zero.  The  following  figure  is  representative  of  this  output. 
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Record  15 


5/21/2009 


Data  item: 

Run  date: 

Options:  YDT 

Time  Observation 

-1 

3684.781683 

-2 

-3 

-4 

-5 

-6 

-7 

-8 

-9 

-10 

1464.751075 

-11 

6218.263807 

-12 

-13 


10000 


0 

3684.781683 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1464.751075 

0 

6218.263807 

0 

0 


Figure  40:  Representative  and  partial  output  of  simulation  file 

The  above  figure  represents  only  a  fraction  of  the  actual  data  collected  in  this  output  file  -  it  is 
merely  representative  of  the  available  data.  It  has  10,000  entries  since  that  was  the  number  of  trials. 
To  make  the  analysis  easier  to  understand,  the  same  data  was  put  into  a  histogram  as  the  following 
graphic  shows. 


Figure  41:  Histogram  of  model  output  at  Milestone  C 
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This  information  indicates  that  the  overall  system  output  has  a  range  between  around  1100 


days  (~  three  years)  to  well  over  8000  days  (~  twenty-two  years),  with  the  majority  of  programs  ending 
between  2300  days  (~  six  years)  and  3200  days  (~  eight  years).  At  first  glance,  as  well  as  comparing  the 
two  samples  in  the  pervious  chapter,  a  high  degree  of  confidence  exists  that  these  outcomes  are 
comparable  to  real  data.  After  iterating  100,000  times,  the  following  figure  shows  the  same  kind  of 
outcomes  as  the  previous  figure. 

Histogram  of  MS  C  arrivals 


13,533  out  of  I  Days 

100,000  trials 

□  Frequency 


Figure  42:  Histogram  of  MS  C  arrivals  after  100000  iterations 

Given  the  outcomes  of  the  previous  figure,  one  would  expect  the  number  of  trials  to  be  around 
an  order  of  magnitude  larger  than  the  figure  representing  10000  trials.  Since  the  model  is  stochastic,  it 
is  expected  that  the  number  of  successful  outcomes  would  not  be  exactly  10  times  the  outcome  shown 
of  the  10,000  iteration  graphic,  and,  it  is  not. 
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This  outcome  also  serves  as  a  sanity  check  on  how  many  runs  are  required  to  achieve  a  stable 


result.  Simulations  with  10000,  48500  and  100000  iterations  were  conducted  to  determine  the  model's 
sensitivity  to  the  different  path  dynamics.  Since  the  model  has  twenty-nine  different  ending  points, 
there  are  potentially  many  thousands  of  paths  through  the  system.  Given  that  48500  iterations  required 
over  three  hours  to  complete  and  that  100000  iterations  required  approximately  ten  hours,  it  was 
important  to  establish  confidence  in  using  sample  sizes  from  the  simulation  model  of  only  10000 
iterations. 


The  following  table  shows  additional  statistics  about  the  outcomes  at  Milestone  C  with  10000 


iterations.  These  statistics  were  calculated  using  Microsoft  Excel's  Data  Analysis  add-in  and  choosing  the 


option  for  descriptive  statistics. 


Simulated  Data  (days) 

Mean 

3755.34 

Median 

3435.38 

Standard  Deviation 

1512.87 

Range 

7338.88 

Minimum 

1119.06 

Maximum 

8457.94 

Program  Count 

1397.00 

Table  17:  Basis  statistics  for  Milestone  C  model  output 

Among  the  items  that  are  interesting  to  note  is  that  the  standard  deviation  at  arriving  at 
Milestone  C  is  over  four  years  and  the  range  between  possible  outcomes  is  about  twenty  years.  These 
ranges  can  partially  be  explained  by  the  multiple  paths  through  the  system  available  for  a  program, 
especially  those  paths  that  allow  for  "direct  entry"  in  the  pre-C  phase  and  also  for  large  programs  that 
are  contentious  in  nature  and  are  being  constantly  revisited.  However,  the  average  often  years  is  about 
right  for  most  programs.  Were  this  data  broken  out  by  ACAT  level,  the  standard  deviations  and  ranges 
of  these  outcomes  would  decrease,  especially  per  the  previous  chapter's  analysis.  The  following  table 
shows  the  basic  statistics  for  100000  iterations. 
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Simulated  Data  (days) 

Mean 

3809.63 

Median 

3482.97 

Standard  Deviation 

1545.92 

Range 

8836.79 

Minimum 

978.61 

Maximum 

9815.40 

Program  Count 

13533.00 

Table  18:  Basic  statistics  for  MS  C  model  output  with  additional  iterations 

This  table  merely  shows  that  while  the  median  and  standard  deviation  for  the  many  runs  stayed 


nearly  the  same  compared  with  the  earlier  table  and  smaller  sample  size,  the  range  increased  as  the 


model  explored  additional  paths  with  lower  probability  of  ever  being  taken.  These  runs  therefore 


increased  the  mean  as  well  as  the  maximum  and  minimum  program  outcomes. 


Other  analyses  done;  preliminary  results 

Close  examination  of  the  simulation  results  suggested  additional  analyses  and  tests  should  be 
done  to  understand  the  capabilities  of  the  model.  Additionally,  it  was  important  to  understand  the 
sensitivities  of  the  model  before  different  research  hypotheses  could  be  tested.  The  additional  tests  are 
looking  for  what  ranges  the  model  continues  to  be  stable  and  under  what  conditions  it  is  unable  to 
reach  an  endpoint  in  the  operation  of  the  model.  Once  this  envelope  is  known  or  understood,  there  can 
be  better  confidence  in  the  research  and  analysis  of  the  hypothesized  tests  to  be  completed. 


Program  End  Points 

One  of  the  surprising  outcomes  was  the  sheer  number  of  programs  that  don't  make  it  "past  the 
word  'go'."  Although  a  cursory  analysis  of  the  probabilities  leading  up  to  these  decision  points 
suggested  it  would  be  a  very  large  number,  the  simulated  outcome  was  the  first  opportunity  to  closely 
examine  the  data  from  the  perspective  of  where  along  the  way  are  programs  killed  and  at  what 
frequency.  The  model  has  twenty-nine  different  exit  points,  of  which  reaching  Milestone  C  is  just  one  of 


154 


them.  Further  information  on  the  exact  meaning  of  the  end  point  names  can  be  found  in  Appendices  D 


and  E. 


Number  of  samples 

9998 

Name  of  Ending  Point 

Early  end;  in  scope  of  existing  document;  outright  rejection 

3444 

34.447% 

new  concepts  after  waiting  period;  rejected 

2754 

27.546% 

remain  in  acq 

1891 

18.914% 

arrive  at  MS  C 

1397 

13.973% 

independent  document  PreC 

82 

0.820% 

2nd  time  requirements  path 

57 

0.570% 

independent  document  preA 

67 

0.670% 

independent  document  PreB 

50 

0.500% 

joint  interest  preC 

34 

0.340% 

1st  time  requirements  path 

33 

0.330% 

1st  time  requirements  path  preC 

36 

0.360% 

joint  interest  PreB 

18 

0.180% 

joint  integration  PreC 

14 

0.140% 

joint  interest  preA 

17 

0.170% 

2nd  time  requirements  preB 

19 

0.190% 

1st  time  requirements  PreB 

12 

0.120% 

2nd  time  requirements  path  preC 

16 

0.160% 

kill  at  MS  C 

18 

0.180% 

joint  integration  preB 

11 

0.110% 

Joint  Integration  PreA 

18 

0.180% 

end  at  COA 

7 

0.070% 

no  AoA 

3 

0.030% 

kill  at  CDR 

0 

0.000% 

stop  MS  B 

0 

0.000% 

pre-MS  C  begin 

0 

0.000% 

kill  at  MS  B 

0 

0.000% 

kill  at  PDR 

0 

0.000% 

concept  selection 

0 

0.000% 

2nd  try  ms  A 

0 

0.000% 

Totals 

9998 

100% 

Table  19:  Analysis  of  model  terminating  points 

At  first  blush,  we  see  that  the  vast  majority  of  programs  never  make  it  into  the  formal 


system.  Between  being  rejected  outright  or  rejected  after  a  small  "socialization"  period,  the  first 
column  of  data  shows  62%  of  programs  end  in  this  manner.  However,  it  still  doesn't  shed  much  insight 


into  overall  model  behavior  and  process  outcomes. 
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Number  of  samples 

3800 

Name  of  Ending  Point 

Early  end;  in  scope  of  existing  document;  outright  rejection 

excluded 

excluded 

new  concepts  after  waiting  period;  rejected 

excluded 

excluded 

remain  in  acq 

1891 

49.76% 

arrive  at  MS  C 

1397 

36.76% 

independent  document  PreC 

82 

2.16% 

2nd  time  requirements  path 

57 

1.50% 

independent  document  preA 

67 

1.76% 

independent  document  PreB 

50 

1.32% 

joint  interest  preC 

34 

0.89% 

1st  time  requirements  path 

33 

0.87% 

1st  time  requirements  path  preC 

36 

0.95% 

joint  interest  PreB 

18 

0.47% 

joint  integration  PreC 

14 

0.37% 

joint  interest  preA 

17 

0.45% 

2nd  time  requirements  preB 

19 

0.50% 

1st  time  requirements  PreB 

12 

0.32% 

2nd  time  requirements  path  preC 

16 

0.42% 

kill  at  MS  C 

18 

0.47% 

joint  integration  preB 

11 

0.29% 

Joint  Integration  PreA 

18 

0.47% 

end  at  COA 

7 

0.18% 

no  AoA 

3 

0.08% 

kill  atCDR 

0 

0.00% 

stop  MS  B 

0 

0.00% 

pre-MS  C  begin 

0 

0.00% 

kill  at  MSB 

0 

0.00% 

kill  at  PDR 

0 

0.00% 

concept  selection 

0 

0.00% 

2nd  try  ms  A 

0 

0.00% 

Totals 

3800 

100.00% 

Table  20:  Analysis  of  model  terminating  points  excluding  early  rejections 

If  these  data  points  are  excluded  from  the  data  sample,  though,  we  learn  that  half  of  all 
programs  get  diverted  into  existing  acquisition  programs  where  they  will  be  accomplished  as  part  of 


another  system's  sustainment  process,  as  shown  in  the  middle  column. 
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Number  of  samples 

1909 

Name  of  Ending  Point 

Early  end;  in  scope  of  existing  document;  outright  rejection 

excluded 

excluded 

new  concepts  after  waiting  period;  rejected 

excluded 

excluded 

remain  in  acq 

excluded 

excluded 

arrive  at  MS  C 

1397 

73.18% 

independent  document  PreC 

82 

4.30% 

2nd  time  requirements  path 

57 

2.99% 

independent  document  preA 

67 

3.51% 

independent  document  PreB 

50 

2.62% 

joint  interest  preC 

34 

1.78% 

1st  time  requirements  path 

33 

1.73% 

1st  time  requirements  path  preC 

36 

1.89% 

joint  interest  PreB 

18 

0.94% 

joint  integration  PreC 

14 

0.73% 

joint  interest  preA 

17 

0.89% 

2nd  time  requirements  preB 

19 

1.00% 

1st  time  requirements  PreB 

12 

0.63% 

2nd  time  requirements  path  preC 

16 

0.84% 

kill  at  MS  C 

18 

0.94% 

joint  integration  preB 

11 

0.58% 

Joint  Integration  PreA 

18 

0.94% 

end  at  COA 

7 

0.37% 

no  AoA 

3 

0.16% 

kill  at  CDR 

0 

0.00% 

stop  MS  B 

0 

0.00% 

pre-MS  C  begin 

0 

0.00% 

kill  at  MS  B 

0 

0.00% 

kill  at  PDR 

0 

0.00% 

concept  selection 

0 

0.00% 

2nd  try  ms  A 

0 

0.00% 

Totals 

1909 

100.00% 

Table  21:  Analysis  of  model  terminating  points  excluding  early  rejected  &  diverted  programs 

If  the  diverted  data  is  also  excluded,  greater  insights  emerge  about  the  behavior  of  the  overall 


formal  system.  For  instance,  we  see  that  nearly  %  of  all  programs  that  formally  enter  the  Acquisition 


system  comprised  of  JCIDS,  PPBE,  and  acquisition,  arrive  at  milestone  C.  Therefore,  the  model  suggests 


that  while  the  initial  entry  barrier  is  high,  once  into  the  system,  the  likelihood  of  eventually  reaching 


Milestone  C  is  very  high. 


A  similar  examination  of  the  proportional  outcomes  with  sample  sizes  of  48500  and 


100000  was  also  accomplished.  Both  have  outcomes  that  are  similar  to  the  outcomes  of  the  sample  size 


of  10000.  See  the  two  figures  below  for  more  details. 
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Table  22:  End  point  summary  statistics  for  sample  of  48500 


Table  23:  End  point  summary  statistics  for  sample  of  100,000 


A  closer  look  at  these  tables  reveals  another  example  of  how  the  larger  sample  sizes 
explores  more  process  paths,  and,  hence,  more  termination  points  than  the  original  sample  size  of 
10,000.  Based  on  the  results  examined,  analysis  based  upon  sample  sizes  of  48500  will  be  used  for  the 
balance  of  all  analysis,  sensitivity  testing  and  hypothesis  testing.  The  choice  of  this  sample  size  balances 
the  time  required  for  processing  and  also  the  increased  fidelity  desired  in  the  model. 
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DSM  representation  and  preliminary  analysis 

There  are  other  methods  available  to  depict  and  analyze  complex  processes.  One  such  method 
is  the  Design  Structure  Matrix.  The  appeal  to  use  DSM  as  a  method  of  representation  and  analysis  is 
from  the  power  resulting  through  the  analysis  available  using  this  form  of  representation.  It  is 
particularly  well-suited  to  complex  systems  that  have  several  tasks  that  are  stochastic  and  cyclical  in 
nature.  For  instance,  in  the  model  developed  for  this  research,  many  of  the  process  tasks  are  identical 
except  for  the  phase  that  the  program  is  in  (e.g.  they  are  given  a  different  name  reflecting  the  milestone 
being  approached).  Nevertheless,  the  size  and  complexity  of  the  current  model  makes  DSM  analysis 
difficult.  Most  research  and  academic  tools  available  do  not  allow  for  the  representation  of  more  than  a 
few  hundred  tasks.  A  MIT-distributed  tool  using  an  Excel  add-in  for  spreadsheets  limits  complexity  at  no 
more  than  approximately  two  hundred  fifty  tasks  [124],  This  version  is  used  to  present  the  following 


analysis. 


At  the  highest  level,  the  following  is  an  example  of  a  DSM  analysis  on  the  top-level  processes. 
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Figure  43:  Partitioned  DSM  of  Acquisition  System 
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The  partitioned  system  shows  three  major  sets  of  clusters.  These  correspond  with  the  different 


acquisition  system  phases  and  a  smaller  set  of  clusters  between  acquisition  and  contractors.  It  also 
shows  upstream  processes  impacting  downstream  ones.  This  is  what  would  be  expected. 

The  three  different  processes  of  requirements,  PPBE,  and  acquisition  all  interact  one  with 
another  and  then  acquisition  and  the  contractor  interact  with  each  other.  This  pattern  repeats  itself 
through  the  three  phases  of  Acquisition  under  this  analysis.  Upstream  requirements  influence  all  of  the 
downstream  chunks.  Each  phase's  PPBE  influences  the  downstream  PPBE  process  and  the  same  is  seen 
for  the  acquisition  process.  There  is  just  not  a  lot  of  detail  present  in  this  DSM  to  draw  many 
conclusions  beyond  those  above.  Therefore,  a  closer  examination  of  the  model  is  warranted  to  ensure 
that  lower-level  activities  are  not  the  source  of  behaviors  of  potential  interest  that  don't  show  up  or  are 
masked  in  this  higher-level  analysis.  DSMs  will  be  used  to  model  each  of  the  three  phases  of  the 
process. 
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Figure  44:  Pre-MS  A  Partitioned  DSM 


Number  of  (asks  in  the  DSM  : 


<note>  new  index  used! 


The  DSM  of  the  Pre-MS  A  phase  of  the  entire  acquisition  process  consists  of  an  89  x  89  matrix 


and  does  not  show  anything  surprising.  The  DSM  analysis  tool  has  partitioned  the  tasks  comprising  the 
DSM  into  31  chunks  and  3  blocks.  In  fact,  the  ordering  of  the  tasks  as  inputs  to  the  partitioning  tool 
were  deliberately  mixed  up  to  see  if  the  tool's  heuristic  would  pull  things  together  properly.  It  did. 

The  three  blocks  identified  by  the  tool  represent  the  approval  process  within  the  Requirements 
system,  the  'concept  decision'  process  in  the  acquisition  swim  lane,  and  the  Milestone  decision  in  the 
acquisition  swim  lane.  The  three  joint  requirement  approval  processes  for  ACAT  I,  II,  or  III  programs 
were  modeled  as  self-contained  processes.  If  they  had  been  broken  out  into  their  constituent  pieces, 
they  likely  would  have  been  'blocked'  as  well  since  their  feedback  loops  and  activities  are  very  similar  to 
those  represented  by  the  blocked  out  areas.  They  had  been  previously  collapsed  because  they  were 
already  self-contained. 

Now,  what  does  this  really  mean?  There  are  a  couple  of  main  takeaways.  First,  approval 
processes  with  potential  for  disapproval  and  resubmission  are  going  to  grind  up  precious  time  in  any 
process  -  perhaps  this  is  where  some  process  improvement  focus  ought  to  be  placed.  Second,  in  the 
Pre-MS  A  Phase,  the  requirements  system  has  two  such  processes,  e.g.  the  approval  through  the  RSR, 
and  any  joint  processes  needed,  and  the  acquisition  system  has  two  such  processes,  e.g.  the  Material 
Concept  decision  and  the  milestone  decision.  Both  of  them  are  going  to  react,  especially  the  acquisition 
system,  to  any  perturbations  in  or  caused  by  the  PPBE  -  which  isn't  modeled  explicitly  because  the 
turbulence  from  this  system  is  expressed  in  the  time  distributions,  e.g.  variance,  of  the  various  modeled 
processes.  Similar  conclusions  are  expected  when  analyzing  the  other  two  phases  of  acquisition  covered 
by  the  model. 
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Figure  46:  Pre-MS  B  Partitioned  DSM 


The  Pre-B  DSM  depicted  in  the  figure  above  is  a  104  x  104  matrix.  It  doesn't  show  much  off- 


diagonal  activity.  The  partitioned  DSM  has  clustered  items  into  28  chunks  and  has  identified  4  major 
blocks  of  activity.  These  blocks  correspond  with  approval  activities  in  the  Pre-Milestone  B  phase.  These 
are:  RFP  Release  and  Source  Selection  with  potential  for  contract  protests;  Requirements  deciding 
whether  to  pursue  the  capability  further;  the  Requirements  approval  processes  at  the  MAJCOM  level; 
and  the  Milestone  B  decision  activities. 

The  four  blocks  are  similar  to  those  in  the  Pre-Milestone  A  Partitioned  DSM  in  that  they  are 
review  processes  that  represent  the  areas  with  the  most  potential  for  rework  and  revisiting  of  decisions. 
The  different  chunks  are  grouped  in  a  manner  that  attempts  to  minimize  the  number  of  disparate  inputs 
and  outputs.  The  activities  contained  within  these  chunks  are  usually  confined  within  a  single  process 
swim  lane.  The  only  real  exceptions  are  those  related  to  financial  questions,  where  a  query  to  the  PPBE 
is  required  to  find  the  answer. 

The  partitioned  DSM  for  the  Pre-Milestone  C  phase  is  similar  to  the  previous  two  DSMs  except 
that  the  number  of  activities  in  the  Pre-Milestone  C  DSM  is  much  greater  than  in  the  previous  DSMs. 

This  is  not  surprising  as  many  more  testing  and  review  activities  are  taking  place  as  the  system  inches 
toward  approval  for  entering  the  last  phase  of  acquisition:  production.  Looking  at  this  DSM,  not  a  lot  of 
significant  off-diagonal  activities  are  seen. 
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Figure  48: 


On 
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The  partitioned  DSM  for  the  Pre-Milestone  C  activity  is  a  132  x  132  matrix,  not  including  the 


processes  associated  with  the  joint  requirements  document  approvals  as  in  the  other  DSMs  shown 
earlier.  This  partitioned  DSM  consists  of  44  chunks  and  7  major  blocks.  The  blocks  represent  the 
following  areas:  the  RFP  and  source  selection  process;  requirements  process  determining  if  they  will 
proceed  in  this  phase;  MAJCOM  requirement  document  approval  process;  Design  Readiness  Review 
activities;  Test  Readiness  Review  activities;  System  Verification  Review  activities;  and  Milestone  C 
approval  activities.  These  blocks  are  where  the  system  activities  are  most  tightly  coupled.  Since  these 
deal  with  approval  processes,  these  results  are  not  surprising.  As  noted  previously,  there  aren't  major 
loop-backs  in  the  model  and  there  isn't  significant  off-diagonal  activity. 

The  combined  DSMs  represent  a  very  linear  process  with  interdependencies  between  three 
differing  stovepipes.  In  practice,  the  system  does  not  go  backward  and  iterate— although  some  might 
argue  that  it  should.  It  may  be  that  these  three  communities  at  the  macro  level  have  evolved  on  fairly 
separate  paths  and  the  model  is  just  reflecting  that.  As  discussed  earlier,  there  are  interdependencies 
in  the  system,  but  each  project  is  not  modeled  with  "memory,"  e.g.  actions  taken  earlier  in  the  lifecycle 
change  the  attributes  of  the  program  in  a  way  that  substantially  affects  the  way  it  is  treated  by 
subsequent  processes.  The  model  already  accommodates  the  memory  effect  through  the  time 
distributions  and  probabilities  that  exist  in  all  of  the  different  model  elements.  Further  work  in  this 
specific  area  is  beyond  scope  of  this  effort. 

Model  Sensitivities 

Returning  to  the  discrete-event  simulation  model,  it  was  deemed  important  to  understand  the 
sensitivities  of  the  model.  A  process  parameter  was  changed  to  see  how  the  change  would  affect  the 
model's  behavior.  The  parameter  in  question  was  changed  in  three  different  places  in  the  model,  pre¬ 
milestone  A,  pre-milestone  B,  and  pre-milestone  C.  For  this  experiment,  a  process  called  "Air  Staff 
process"  in  the  Requirements  swim  lane  was  modified  in  the  Joint,  Joint  Integration,  and  Independent 
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document  processes.  One  of  these  three  steps  must  be  met  by  all  programs  going  through  the 
Requirements  swim  lane— and  the  different  processes  named  correspond  to  the  ACAT  level  of  the 
program. 

The  original  model  data  will  be  compared  to  the  changed  model  data.  The  output  at  MS  C  will 
be  the  data  point  used  for  the  comparisons  between  the  two  models.  The  original  data  for  the  air  staff 
process  in  the  Independent  and  Joint  Integration  processes  use  a  triangular  input  of  21,  25,  and  42  days. 
The  changed  model  uses  triangular  probability  data  of  21,  25,  and  42  hours,  e.g.  a  switch  in  the  model 
was  changed  from  "days"  to  "hours."  The  original  data  for  the  Joint  document  process  uses  a  slightly 
different  triangular  input  of  21,  29,  and  42  days.  The  changed  model  uses  data  of  21,  29,  and  42  hours. 

The  outcome  data  shows  that  by  changing  this  one  process  activity,  "air  staff  process,"  has  a 
relatively  small  impact  in  terms  of  the  final  outcomes,  even  if  this  process  is  repeated  three  times,  e.g. 
one  time  per  model  phase.  The  changed  data  is  really  not  significant  in  terms  of  the  final  outcome.  The 
tables  below  show  that  the  average  time  through  the  system  with  the  changed  model  only  decreases 
slightly.  A  simple  explanation  for  this  outcome  could  be  that  although  the  air  staff  process,  while  on  the 
critical  path,  e.g.  all  programs  must  go  through  it,  of  the  Requirements  process,  is  mitigated  by  other 
processes  and  their  effects  in  other  swim  lanes. 


Baseline  data  (days) 


Mean 

3806.63 

Standard  Error 

19.04 

Median 

3472.15 

Standard  Deviation 

1546.24 

Range 

8696.34 

Minimum 

1119.06 

Maximum 

9815.40 

Program  Count 

6593.00 

Table  24:  Original  Model  data  outcomes  at  MS  C 
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Air  Staff  Intervention  data  (days) 

Mean 

3780.65 

Standard  Error 

18.58 

Median 

3460.95 

Standard  Deviation 

1515.31 

Range 

8296.83 

Minimum 

1135.29 

Maximum 

9432.11 

Program  Count 

6653.00 

Table  25:  Changed  model  outcomes  at  MS  C 


Additional  Questions  using  Sensitivity  Test  Data 

Is  the  total  impact  of  the  changes  examined  above  masked  by  all  of  the  different  potential  paths 


through  the  model  to  make  it  to  MS  C?  Would  the  change  to  the  model  be  more  significant  if  only 


programs  that  went  through  the  entire  "formal"  process  were  examined?  The  following  data  examines 


exactly  that  scenario  and  reveals  the  following: 


original  model  -  no  excursions  allowed  (days) 


Mean 

5129.02 

Standard  Error 

24.29 

Median 

4913.12 

Standard  Deviation 

1241.88 

Range 

7007.52 

Minimum 

2807.89 

Maximum 

9815.40 

Program  Count 

2613.00 

Table  26:  Original  model  outcomes  at  MS  C  with  no  excursions  allowed 


air  staff  intervention 

-  no  excursions  allowed  (days) 

Mean 

5063.49 

Standard  Error 

23.58 

Median 

4834.03 

Standard  Deviation 

1213.97 

Range 

6856.13 

Minimum 

2575.99 

Maximum 

9432.11 

Program  Count 

2650.00 

Table  27:  Air  staff  intervention  model  outcomes  at  MS  C  with  no  excursions  allowed 
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Temporarily  overlooking  the  fact  that  programs  that  only  go  through  the  formal  process  take 


longer  to  make  it  to  MS  C,  the  experimental  results  confirm  the  previous  conclusions:  changing  the 
model  parameters  in  the  air  staff  process  module  did  not  change  the  model  outcomes  significantly,  even 
when  ensuring  the  programs  met  this  process  a  total  of  three  times  or  once  each  phase.  On  average, 
the  air  staff  process  required  approximately  25  days  to  complete  per  time  encountered,  and  in  this 
experiment,  the  difference  in  the  means  between  the  original  outcomes  and  the  intervention  outcomes 
is  approximately  66  days,  close  to  an  average  of  22  days  duration  for  each  time  encountered.  This  is 
certainly  reasonable  given  the  original  triangular  distribution  of  the  process  data.  These  results  increase 
confidence  in  the  overall  operation  of  the  model. 

Other  Questions 

Based  on  the  above  sensitivity  testing,  does  the  outcome  data  between  results  that 
were  allowed  to  get  to  MS  C  by  any  path  and  those  forced  to  traverse  the  entire  formal  system  reveal 
anything  significant?  A  visual  comparison  of  histograms  between  the  two  data  sets  follows. 
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Histogram  of  programs  -  comparision  of  paths  through  system 


□  Abbreviated  process  path  ■  Full  Process  Path] 


Figure  50:  Comparison  of  MS  C  arrivals  between  forced  formal  system  and  any  shortcuts 

This  graph  does  not  show  anything  particularly  new,  but  illustrates  some  of  the  reasons  why  any 
circumvention  around  the  formal  system  is  preferred.  It  almost  always  results  in  a  program  that  reaches 
MS  C  before  a  formal  system  would.  While  the  graph  merely  depicts  how  the  model  is  programmed,  it 
shows  how  programs  prefer  to  go  down  these  alternative  paths.  Both  process  paths  also  show  the 
extended  tail  on  the  right,  indicating  some  of  the  system  effects  of  the  reviews  and  potential  pitfalls 
faced  by  a  program  during  its  development  prior  to  MS  C.  As  noted  in  earlier  chapters,  retaining 
flexibility  in  program  execution  is  highly  prized  and  graphically  we  see  the  range  of  possible  results.  The 
downside  to  the  behavior  of  this  system  is  that  its  stochastic  nature  and  the  wide  range  of  potential 
outcomes  make  it  difficult  to  forecast  program  completion  times  with  a  great  deal  of  accuracy. 

Further  Model  Results  and  Analysis 

Additional  examination  of  various  data  from  the  model  results  in  a  better  understanding  the 
operation  of  the  model.  This  data  lends  insights  into  the  actual  overall  operation  of  the  enterprise 
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system.  The  following  questions  can  be  answered  by  looking  at  the  data  collected  at  various  points 
throughout  the  model  since  the  robustness  of  the  modeling  environment  allows  for  ample  and  easy 


data  collection. 


Data  analysis  of  48500  sample  size 

Count 

Percentage  overall 

"Programs"  dismissed  outright  at  the 

MAJCOM  level 

16982 

35%  of  48500  sample 

Programs  dismissed  after  a  "socialization" 
period  with  the  MAJCOM 

13111 

27%  of  48500  sample 

Programs  that  enter  sustainment 
acquisition  after  going  through  an  initial 

MAJCOM  filter 

10424 

21.5%  of  48500  sample 

Programs  that  go  through  any  portion  of 
the  formal  system  after  initial  MAJCOM 

filters 

9024 

18.6%  of  48500  sample 

Programs  that  are  killed  at  various 
screens,  decision  points,  and  other  places 
within  the  formal  process 

2431 

5%  of  48500  sample;  27%  of  9024  in  any  part  of 
formal  system 

Programs  that  actually  enter  the  formal 
system  via  any  process  and  make  it  to 

Milestone  C 

6593 

13.6%  of  48500  sample 

Programs  that  circumvent  any  portion  of 
the  system  and  make  it  to  Milestone  C 

3980 

8.2%  of  48550  sample; 

60.4%  of  6593  MS  C  success 

Programs  that  originally  enter 

sustainment  that  re-enter  the  formal 

system 

1041 

2.1%  of  48500  sample;  10%  of  10424  programs 
going  to  sustainment 

Programs  that  originally  enter 

sustainment  that  re-enter  the  formal 

system  and  make  it  to  Milestone  C 

886 

1.8%  of  48500  sample;  13.4%  of  all  6593  MS  C 
successes;  8.5%  of  10424  in  sustainment;  85.1% 
success  in  reaching  MS  C  from  sustainment  entry 

Programs  via  direct  entry  into  the  formal 
system  that  start  process  other  than  at 
the  formal  process  beginning 

3578 

7.4%  of  48500  sample 
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Programs  via  direct  entry  that  arrive  at 

MS  C  (do  not  go  through  sustainment 
first) 

3094 

6.4%  of  48500  sample;  86.5%  success  rate  of  the 
3578  direct  entry  programs 

Programs  that  enter  formal  system  at 
beginning 

4405 

9%  of  48500  sample 

Programs  from  beginning  of  formal 
system  that  arrive  at  MS  C 

2613 

5.3%  of  48500  sample;  59.3%  of  4405  complete 
formal  system 

Overall  yield  arriving  at  MS  C  vs  those  that 

enter  system 

N/A 

73.1% 

Table  28:  Additional  Data  Analysis 


Some  initial  observations  are  that  once  a  system  "enters"  the  formal  acquisition  system, 
it  has  a  better  than  even  chance  of  making  it  to  Milestone  C.  As  noted  above,  a  program's  best  chance 
for  success  is  to  enter  the  system  somewhere  other  than  the  "beginning"  of  the  formal  system.  Chances 
increase  from  about  a  60%  success  rate  for  a  program  entering  at  the  beginning  to  more  than  an  85% 
success  rate  for  programs  entering  the  formal  system  elsewhere  along  the  line.  A  graphical  depiction  of 
this  table  may  make  it  easier  to  understand  the  particular  nuances  of  the  system. 
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Experimental  Model  outcomes  of  48500  sample  programs 


34%  outright  rejection  (16982) 

27%  rejected  after  waiting  period  (13111) 

21%  are  sent  to  sustainment  (10424) 

2.1%  back  into  process  (1041) 

7%  by-pass  parts  of  formal  system  (3578)* 

*  In  scope  of  existing  Requirements  document 

9%  enter  formal  system  (4405) 


Figure  51:  Graphical  depiction  of  model  outcomes 

Additionally,  a  few  quick  observations  can  be  made  about  the  probability  of  different 


parts  of  the  system  to  eliminate  programs  along  the  way.  For  instance,  of  the  9024  programs  that 


experience  any  part  of  the  formal  system,  2344  of  them,  or  about  26%,  are  killed  by  processes  within 


the  Requirements  Swim  Lane  across  the  three  phases  of  the  formal  system. 


Analysis  of  leading/trailing  edges  of  Requirements 

arocess 

trailing  edge  kill  rate 

1527  65.1% 

leading  edge  kill  rate 

817  34.9% 

2344  100.0% 

Pre-A 

percent 

Pre-B 

precent 

Pre-C 

percent 

trailing  edge 

447 

51.1% 

388 

70.4% 

692 

75.4% 

leading  edge 

428 

48.9% 

163 

29.6% 

226 

24.6% 

875 

100.0% 

551 

100.0% 

918 

100.0% 

37.3% 

23.5% 

39.2% 

total 

2344 

Table  29:  Requirements  swim  lane  analysis 

The  table  above  elucidates  this  capability  of  the  requirements  swim  lane  to  reject  or  kill 
programs.  The  terms  "leading  edge"  and  "trailing  edge"  refer  to  the  MAJCOM  process  and  the  Air 
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Staff/Joint  process  respectively.  Overall,  the  air  staff/joint  processes  eliminate  programs  at  a  greater 


than  two  to  one  ratio  than  the  MAJCOM  processes  do.  Closer  examination  shows  that  both  systems 
eliminate  programs  in  the  earliest  phases  at  a  nearly  equal  amount.  However,  as  a  program  continues 
later  in  the  process,  the  MAJCOM  requirements  process  lags  the  air  staff/joint  processes  in  program 
elimination  by  a  significant  margin.  A  simple  and  rational  explanation  is  that  the  longer  a  program  is  in 
the  formal  system,  the  more  attached  the  MAJCOM  becomes  to  a  program.  Such  attachment  can  be 
explained  by  reliance  upon  "sunk  costs"  as  well  as  building  enthusiasm  within  the  MAJCOM  for  delivery 
of  the  system  in  development.  Air  Staff  and  Joint  processes  seem  to  retain  the  ability  to  be  objective  or 
prudent  to  other  realities,  be  they  fiscal  or  other  situations.  Still,  these  observations  must  be  made  in 
light  of  the  74%  of  other  programs  that  make  it  through  this  swim  lane  successfully. 

Finally,  the  ability  of  the  acquisition  portion  of  the  system  to  actually  eliminate  or  kill  a 
program  is  highly  constrained.  Only  about  one  percent  of  programs  in  any  part  of  the  formal  system  are 
eliminated  through  the  acquisition  swim  lane.  From  a  rational  perspective,  this  result  also  makes  sense. 
The  Milestone  Decision  Authority,  although  it  has  the  authority  to  kill  programs,  rarely  does  so.  Even  at 
technical  reviews,  where  there  is  also  a  possibility  of  killing  a  program,  the  system  is  very  "forgiving"  of 
programs  that  don't  pass  these  reviews.  By  its  own  admission,  the  acquisition  swim  lane  usually 
implements  a  "get  well  plan"  versus  terminating  a  poorly  performing  program.  Cost  and  schedule  is 
easily  traded  whereas  performance  or  quality  is  rarely  traded  in  this  swim  lane. 

Conclusions 

This  chapter  examined  the  model,  its  performance  and  preliminary  or  baseline  data 
results.  Analysis  to  determine  a  robust  sample  size  was  completed  as  well  as  using  Design  Structure 
Matrix  analyses  techniques.  The  results  of  these  efforts  lend  credibility  to  the  verification  and  validation 
discussed  in  the  previous  chapter.  The  DSM  analysis  also  showed  how  the  system  is  very  linear  in 
practice  and  rather  than  having  large  feedback  or  feed-forward  loops,  shows  how  the  system  can  "bog 
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down"  in  place  until  problems  or  issues  are  resolved.  Additional  analysis  reveals  the  effects  of  the 
model's  probabilistic  features  and  resulting  outcomes  of  the  model.  Efforts  at  sensitivity  testing  show 
the  model  behaves  as  expected  and  further  analysis  gives  insight  into  the  effectiveness  of  different  swim 
lane  processes. 

The  model's  outcomes  using  a  reasonable  sample  size  form  a  healthy  baseline  of 
expected  system  performance  and  also  set  the  standard  against  which  different  hypotheses  and 
interventions  can  be  tested  and  examined. 
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CHAPTER  8  --  HYPOTHESIS  TESTING  AND  ANALYSIS 

Given  that  the  model  has  been  tested,  verified  and  validated,  priority  can  be  given  to  posing 
experimental  questions  to  see  how  the  model  behaves.  The  data  from  the  model  can  reveal  how  the 
system  responds  to  those  questions  and  provide  insight  into  the  overall  performance  of  the  system. 

Adding  to  the  motivation  of  exploring  various  questions,  several  external  factors  have  emerged 
that  have  influenced  which  questions  should  be  tested.  Among  these  are  a  memo  from  the  Department 
of  Defense's  Undersecretary  of  Acquisition,  Ashton  Carter,  on  12  May  2009  [125];  the  release  of  the  new 
DOD  5000  series  of  instructions  regarding  acquisition  in  December  2008  [126];  the  release  of  an  updated 
version  of  JCIDS  in  March  2009  [127];  and  the  release  of  a  National  Academies  of  Sciences  report  in  June 
2009  [128]  about  some  of  the  changes  being  proposed  for  acquisition. 

The  memo  by  Ashton  Carter  indicates  the  Department  of  Defense  is  going  to  improve  its 
acquisition  processes  by  making  improvements  in  systems  engineering,  developmental  test  and 
evaluation,  technological  maturity,  and  cost  estimation.  The  DOD  5000.02  update  also  makes  some 
changes  in  the  overall  acquisition  process.  The  most  notable  of  these  is  requiring  that  all  projects  be 
evaluated  prior  to  entry  into  any  part  of  the  acquisition  system,  as  well  as  changing  the  emphasis 
different  engineering  reviews  will  receive.  The  new  evaluation  can  be  likened  to  a  major  review 
required  prior  to  entering  any  portion  of  the  acquisition  system.  This  change  directly  addresses  some 
criticisms  leveled  at  the  old  system  that  allowed  programs  to  "enter"  the  system  at  any  point  the 
sponsor  deemed  appropriate.  Some  additional  technical  reviews  are  also  proposed.  The  JCIDS  update 
primarily  harmonizes  its  processes  with  the  updates  listed  in  the  5000.02  instruction  and  also 
emphasizes  the  importance  of  proper  analyses  and  thorough  evaluation  of  all  needs  before  turning  to 
materiel  solutions.  The  NAS  report  draws  some  interesting  conclusions  that  are  not  easily  testable  but 
are  relevant  to  this  work  and  contribute  in  an  anecdotal  way.  One  of  which  is  skepticism  about  the 
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increasing  frequency  of  program  reviews  and  questioning  the  value  these  reviews  impart  to  the  program 


relative  to  the  time  and  effort  expended. 

Hypothesis 

It  goes  without  saying  that  "all  models  are  wrong,  but  some  are  useful57."  In  light  of  this  truism, 
the  main  hypothesis  of  this  work  will  attempt  to  use  the  developed  model,  but  also  acknowledge  its 
shortcomings. 

The  hypothesis  states:  "Well  thought-out  interventions  to  the  overall  acquisition  system  will 
improve  the  performance  and  outcomes  of  the  entire  acquisition  system." 

The  existing  model  of  the  overall  acquisition  system  will  be  used  to  test  this  hypothesis.  These 
interventions  will  be  structured  in  the  model  in  a  way  that  attempts  to  accurately  correspond  to  real-life 
implementation.  Furthermore,  "improvement"  will  be  determined  based  upon  an  intervention's  impact 
to  schedule  or  performance58.  However,  the  results  of  any  interventions  implemented  in  the  model  will 
likely  represent  a  lower  or  upper  bound  of  possible  outcomes  in  the  real  world  system  as  the  model 
itself  tends  to  be  extremely  conservative  in  its  results.  Much  of  this  conservatism  comes  from  the  time 
distributions  that  were  gathered  from  expert  input.  For  instance,  the  time  distributions  at  individual 
process  steps  already  reckon  or  account  for  many  of  the  inherent  systemic  issues  in  the  task  at  hand. 
However,  if  a  change  is  made  that  improves  the  system,  the  mental  framing  or  task  accounting  that 
takes  place  in  the  mind  of  these  experts  would  change  and  adapt  to  the  overall  systemic  change  thereby 
changing  the  time  distribution  of  that  particular  process.  In  other  words,  the  model  does  not  have  or 
demonstrate  any  "memory  effects"  that  would  be  manifested  via  a  change  made  early  in  the  system  and 
would  then  propagate  through  the  rest  of  the  system.  This  conservatism  was  discussed  earlier  as  it 

57  This  quote  has  been  attributed  to  George  Box,  a  noted  Industrial  Statistician 

58  Future  work  would  extend  the  model's  capabilities  to  "cost." 
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stems  from  the  way  the  model  is  structured  and  how  the  main  unit  of  analysis  is  an  individual  program. 


Please  see  Chapters  5  through  7  for  more  detailed  explanation  about  the  workings  of  the  model. 

Key  Questions 

The  key  questions  relating  to  this  hypothesis  are:  "How  does  the  model  respond  to  interventions 
patterned  after  some  of  the  proposed  changes  to  the  overall  system?"  "Will  there  be  any  improvement 
in  the  total  time  required  for  a  program  to  arrive  at  MS  C?"  "Will  there  be  any  improvement  in  overall 
process  quality?" 

Detailed  explanations  of  how  these  interventions  are  structured  to  represent  reality  and  model 
it  correctly  will  be  given.  The  results  of  the  experimentation  will  also  be  given  along  with  an  analysis  of 
the  outcome  data.  All  results  will  be  normalized  against  the  original  model  baseline  mean  and 
significant  differences  will  be  explained  and  analyzed. 

The  benefit  of  using  this  model  to  test  these  interventions  is  that  many  different  tests  can  be 
run  and  examined  whereas  changing  the  existing  system  would  require  years  of  patience  and  careful 
monitoring  before  any  such  benefits  to  these  interventions  could  ever  be  measured  or  realized. 
Furthermore,  there  is  only  a  small  sample  size  "active"  in  the  system  at  any  given  time  -  on  the  order  of 
100  to  200  programs  -  and  therefore  the  likelihood  of  seeing  all  potential  system  outcomes  is  remote. 
Perhaps  these  are  two  of  the  major  difficulties  existing  in  the  system,  as  many  different  interventions 
are  attempted  without  being  able  to  discern  any  impacts  these  interventions  have  provided  before 
additional  interventions  are  made  -  thus  complicating  the  judgment  about  the  efficacy  of  any  real-world 
intervention. 

Experimental  Interventions 

Twenty  different  interventions  were  evaluated.  In  the  following  pages,  each  intervention  will  be 
grouped  and  discussed  according  to  the  portion  of  the  system,  e.g.  which  swim  lane,  in  which  the 
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primary  intervention  takes  place.  This  is  a  useful  way  to  systematically  experiment  through  the  model 


and  also  corresponds  to  likely  interventions  that  would  be  taken  in  the  actual  system  since  the  individual 
swim  lanes  are  governed  and  controlled  by  different  organizations. 

The  results  of  these  interventions  will  be  compared  to  the  original  model  baseline  and  shown  in 
a  tabular  format.  The  first  two  columns  will  always  be  the  same.  The  first  column  represents  the  actual 
model  data  from  the  original  model  baseline.  The  second  column  represents  "normalized"  values  of  the 
first  column  of  data.  The  data  is  being  normalized  to  the  mean  duration  of  the  original  model.  The 
mean,  standard  error,  median,  standard  deviation,  sample  variance,  range,  minimum,  and  maximum 
were  divided  by  the  mean  of  the  original  model  baseline.  For  instance,  the  "normalized"  baseline  for 
the  mean  duration  to  MS  C  is  equal  to  1.0.  Normalizing  the  data  will  allow  more  accurate  comparisons 
to  be  made  between  the  outcomes  of  the  different  interventions.  The  third  column  will  contain  the 
specified  intervention  outcomes  of  the  above  named  measures  "normalized"  to  the  original  model 
baseline  value.  The  fourth  column  indicates  the  differences  between  the  two  normalized  columns.  This 
last  column  is  where  any  significant  impacts  of  the  interventions  will  be  easily  seen.  A  discussion  of  the 
larger  differences  and  their  possible  meaning  will  accompany  the  tabular  output. 

Requirements  Swim  Lane  Interventions 

"Air  Staff  Intervention" 

This  intervention  explores  what  will  happen  with  the  model  outcomes  if  the  process  step  "Air 
Staff"  is  minimized.  Practically  speaking,  this  intervention  is  an  attempt  to  see  how  the  model  reacts  if  a 
component  is  eliminated  from  the  system  or  what  would  happen  if  a  step  on  the  "critical  path"  of  this 
swim  lane  is  removed.  The  "Air  Staff"  process  step  refers  to  the  process  where  the  Air  Staff  coordinates 
the  review  of  a  given  JCIDS  document  between  the  other  services  and  also  different  MAJCOMs.  This 
step  is  encountered  by  every  Requirements  document  as  it  passes  between  the  MAJCOM  and  the  more 
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'formalized"  portion  of  JCIDS.  This  particular  intervention  was  also  discussed  in  Chapter  7  under  the 


heading  of  "Model  Sensitivities." 


Are  there  any  coupling  effects  that  would  drastically  change  the  way  the  model  behaves  or  will 


the  model  outcomes  change  in  a  linear  fashion,  e.g.  a  1  for  1  reduction  in  time? 


Normalized 


Exit  at  MS  C 

Baseline 

Baseline 

air  staff  intervention 

Delta 

Mean  (days) 

3806.63 

1.00 

0.99 

0.01 

Standard  Error 

19.04 

0.01 

0.00 

0.00 

Median  (days) 

3472.15 

0.91 

0.91 

0.00 

Standard  Deviation  (days) 

1546.24 

0.41 

0.40 

0.01 

Sample  Variance 

2390873.19 

0.16 

0.16 

0.01 

Kurtosis 

-0.07 

-0.07 

-0.08 

0.02 

Skewness 

0.76 

0.76 

0.74 

0.01 

Range  (days) 

8696.34 

2.28 

2.18 

0.10 

Minimum  (days) 

1119.06 

0.29 

0.30 

0.00 

Maximum  (days) 

9815.40 

2.58 

2.48 

0.10 

Program  Count 

6593.00 

6593.00 

6653.00 

-60.00 

Arrive  at  MS  C 

6593.00 

1.00 

1.01 

-0.01 

Table  30:  Air  Staff  intervention  results 

These  results  do  indicate  a  linear  relationship  exists.  When  looking  at  the  mean  of  all  the 
experimental  results,  it  compares  very  favorably  with  the  baseline.  However,  those  programs  that  are  at 
the  maximum  duration  (or  those  that  run  into  problems  and  have  to  repeat  certain  portions  of  the 
system)  find  that  the  elimination  of  this  one  step  reduces  the  potential  time  by  a  multiplier  of  0.1  from 
the  mean  outcome.  The  minimum  does  not  change,  but  the  maximum  duration  changes.  Instead  of 
taking  2.58  times  the  mean  for  the  maximum  duration  program,  it  only  requires  2.48  times  the  baseline 
for  maximum  duration  program.  For  further  explanation,  in  all  likelihood,  the  baseline  maximum 
encountered  random  air  staff  processes  at  the  maximum  time  for  that  process  during  the  three  phases 
between  milestones  A  and  C  and  the  intervention  maximum  didn't  have  to  deal  with  these  processes  at 
all. 
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"MAJCOM  approval  bodies" 


This  intervention  is  designed  to  eliminate  any  calendar  waiting  time  in  the  MAJCOM 


requirements  swim  lane  and  approval  process.  The  meaning  of  this  intervention  would  be  similar  to 


increasing  the  capacity  of  the  approval  process  portion  of  the  system  in  that  people  are  always  readily 


available  to  consider  any  requirement  document  for  approval.  There  is  no  waiting  time  to  approach  the 
proper  individuals  for  approvals.  What  kind  of  impact  will  making  this  change  cause? 


Normalized 


Exit  at  MS  C 

Baseline 

Baseline 

MAJCOM  approval  bodies 

Delta 

Mean  (days) 

3806.63 

1.00 

0.99 

0.01 

Standard  Error 

19.04 

0.01 

0.00 

0.00 

Median  (days) 

3472.15 

0.91 

0.91 

0.00 

Standard  Deviation  (days) 

1546.24 

0.41 

0.40 

0.01 

Sample  Variance 

2390873.19 

0.16 

0.16 

0.01 

Kurtosis 

-0.07 

-0.07 

-0.02 

-0.05 

Skewness 

0.76 

0.76 

0.77 

-0.01 

Range  (days) 

8696.34 

2.28 

2.04 

0.24 

Minimum  (days) 

1119.06 

0.29 

0.30 

0.00 

Maximum  (days) 

9815.40 

2.58 

2.34 

0.24 

Program  Count 

6593.00 

6593.00 

6549.00 

44.00 

Arrive  at  MS  C 

6593.00 

1.00 

0.99 

0.01 

Table  31:  MAJCOM  approval  bodies  result 

These  results  indicate  similar  outcomes  as  the  other  intervention  in  this  swim  lane.  There  is 


virtually  no  change  in  the  mean  program  outcome  as  well  as  no  changes  in  the  "shape"  of  the 
distribution  curve.  The  "shape"  can  indicate  quality  impacts,  e.g.  skewness  away  from  the  mean  or 
kurtosis  indicating  the  clustering  around  the  mean,  if  the  overall  distribution  becomes  more  narrow,  e.g. 
the  variance  is  reduced,  or  the  range  of  the  distribution  is  narrowed,  e.g.  the  overall  program  length  is 
reduced  by  a  factor  of  0.24  from  the  mean  baseline  program  length.  In  this  case,  only  the  maximum 
program  length  is  affected  as  in  the  previous  intervention.  This  is  explained  by  a  program  going  through 
the  entire  process,  e.g.  three  approval  processes  for  each  milestone,  at  the  maximum  duration. 
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"Critical  Comments" 


This  intervention  is  designed  to  eliminate  the  process  of  critical  comments,  an  existing  process 
step  in  the  requirements  swim  lane  whereby  a  requirements  document  can  be  held  up  to  adjudicate 
comments  to  a  requirements  process.  The  process  owners  indicated  a  great  deal  of  frustration  with 
"critical  comments"  that  held  up  a  document  in  the  approval  process.  This  step  kicks  off  a  large  "redo" 
loop  to  address  those  comments.  In  this  case,  the  model  was  modified  so  that  there  would  be  zero 
probability  of  a  document  having  any  critical  comments.  The  results  follow. 


Normalized 


Exit  at  MS  C 

Baseline 

Baseline 

critical  comments 

Delta 

Mean  (days) 

3806.63 

1.00 

0.99 

0.01 

Standard  Error 

19.04 

0.01 

0.00 

0.00 

Median  (days) 

3472.15 

0.91 

0.90 

0.01 

Standard  Deviation  (days) 

1546.24 

0.41 

0.40 

0.01 

Sample  Variance 

2390873.19 

0.16 

0.16 

0.00 

Kurtosis 

-0.07 

-0.07 

-0.06 

-0.01 

Skewness 

0.76 

0.76 

0.77 

-0.02 

Range  (days) 

8696.34 

2.28 

2.05 

0.23 

Minimum  (days) 

1119.06 

0.29 

0.29 

0.00 

Maximum  (days) 

9815.40 

2.58 

2.34 

0.23 

Program  Count 

6593.00 

6593.00 

6517.00 

76.00 

Arrive  at  MS  C 

6593.00 

1.00 

0.99 

0.01 

Table  32:  Critical  comments  results 

These  results  also  indicate  very  little  difference  from  the  other  interventions  studied.  There  is  a 


0.23  factor  difference  on  the  maximum  outcome  of  the  intervention  compared  to  the  mean. 


Planning,  Programming,  Budgeting,  Execution  System  Swim  Lane 
Interventions 

"Funding  Stability" 

This  intervention  addresses  one  of  the  other  main  issues  listed  by  multiple  studies  as  well  as 
interviews  conducted  for  this  study.  The  feeling  was  that  the  instability  caused  by  funding  changes  had 
a  dramatic  impact  on  the  overall  system  outcomes.  For  this  intervention,  the  probability  that  any 
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chance  of  funding  instability  occurred  during  any  phase  was  eliminated.  Furthermore,  the  probability 


that  funding  was  not  available  for  any  study  or  activity  at  the  time  such  funding  was  required  was  also 


reduced  to  zero.  The  results  follow. 


Exit  at  MS  C 

Baseline 

Normalized 

Baseline 

Funding  Stability 

Delta 

Mean  (days) 

3806.63 

1.00 

0.96 

0.04 

Standard  Error 

19.04 

0.01 

0.00 

0.00 

Median  (days) 

3472.15 

0.91 

0.88 

0.03 

Standard  Deviation  (days) 

1546.24 

0.41 

0.38 

0.03 

Sample  Variance 

2390873.19 

0.16 

0.14 

0.02 

Kurtosis 

-0.07 

-0.07 

-0.30 

0.23 

Skewness 

0.76 

0.76 

0.66 

0.09 

Range  (days) 

8696.34 

2.28 

1.83 

0.46 

Minimum  (days) 

1119.06 

0.29 

0.29 

0.00 

Maximum  (days) 

9815.40 

2.58 

2.12 

0.46 

Program  Count 

6593.00 

6593.00 

6554.00 

39.00 

Arrive  at  MS  C 

6593.00 

1.00 

0.99 

0.01 

Table  33:  Funding  Stability  Results 

The  model  suggests  that  this  particular  intervention  does  make  a  difference  -on  the  order  of 


approximately  4%.  The  mean  is  4%  less  than  the  baseline  and  the  median  is  reduced  by  a  similar 
amount,  3%.  Furthermore,  the  kurtosis  narrowed  considerably  -  noted  by  the  change  from  the  baseline 
of  0.23.  Finally,  the  range  of  the  distribution  also  narrowed  considerably,  by  a  factor  of  0.46.  Therefore, 
the  intervention  does  make  a  difference.  Even  so,  the  magnitude  of  this  result  was  much  less  than 
expected.  Further  examination  of  this  phenomenon  will  be  future  work. 


Acquisition  Swim  Lane  Interventions 

"Acquisition  Kill" 

This  intervention  increased  the  probability  that  a  program  has  the  potential  to  be  killed  at  every 
acquisition  decision  point.  Rather  than  every  milestone  decision  point  and  concept  selection  decision 
point  being  highly  likely  to  succeed,  the  intervention  changed  this  probability  to  just  50%.  Far  fewer 
programs  should  make  it  to  MS  C.  Are  there  other  effects  on  the  system  with  this  intervention? 
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Normalized 

Exit  at  MS  C 

Baseline 

Baseline 

Acquisition  Kill 

Delta 

Mean  (days) 

3806.63 

1.00 

0.91 

0.09 

Standard  Error 

19.04 

0.01 

0.01 

0.00 

Median  (days) 

3472.15 

0.91 

0.81 

0.10 

Standard  Deviation  (days) 

1546.24 

0.41 

0.38 

0.03 

Sample  Variance 

2390873.19 

0.16 

0.14 

0.02 

Kurtosis 

-0.07 

-0.07 

1.19 

-1.26 

Skewness 

0.76 

0.76 

1.20 

-0.45 

Range  (days) 

8696.34 

2.28 

2.27 

0.01 

Minimum  (days) 

1119.06 

0.29 

0.31 

-0.01 

Maximum  (days) 

9815.40 

2.58 

2.58 

0.00 

Program  Count 

6593.00 

6593.00 

3574.00 

3019.00 

Arrive  at  MS  C 

6593.00 

1.00 

0.54 

0.46 

Table  34:  Acquisition  Kill  results 

These  results  show  a  significant  impact  on  the  mean,  the  kurtosis,  the  skewness,  and  the 
total  number  of  programs  that  actually  make  it  to  MS  C.  What  this  intervention  clearly  shows  is  that 
changing  the  probability  of  going  forward  in  the  system  does  make  a  significant  difference.  However,  it 
still  does  not  change  any  process  variance.  Therefore,  the  range  of  the  distribution  does  not  change  at 
all.  What  has  also  happened  is  that  since  the  majority  of  programs  circumvent  some  portion  of  the 
system,  it  meets  these  potential  kill  points  less  frequently  than  those  programs  that  go  through  the 
entire  system.  The  result  is  that  more  systems  are  killed  that  go  through  the  entire  process.  What  this 
does  it  that  it  shifts  the  mean  of  all  outcomes  to  the  left,  the  distribution  remains  skewed  to  the 
maximum  program  outcome  and  the  tightness  of  the  mean  has  flattened  out.  The  final  result  is  that  at 
MS  C  programs  that  skip  portions  of  the  process  are  even  more  favored  than  before  and  the  proportion 
of  programs  that  have  skipped  a  portion  of  the  process  increases  substantially. 

"Approval  Body" 

This  intervention  targets  those  processes  in  the  acquisition  swim  lane  immediately  prior  to 
Acquisition  Panel  activities  or  more  simply,  a  calendar  waiting  activity.  This  intervention  eliminates 
these  waiting  periods.  The  intervention  is  akin  to  the  acquisition  process  becoming  more  agile  and 
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responsive  to  approval  activities  than  ever  before.  In  some  sense,  there  is  extra  capacity  available  for 


these  approval  bodies  to  meet  without  delay.  The  results  of  this  intervention  follow. 


Normalized 


Exit  at  MS  C 

Baseline 

Baseline 

Approval  body 

Delta 

Mean  (days) 

3806.63 

1.00 

0.98 

0.02 

Standard  Error 

19.04 

0.01 

0.00 

0.00 

Median  (days) 

3472.15 

0.91 

0.90 

0.01 

Standard  Deviation  (days) 

1546.24 

0.41 

0.39 

0.02 

Sample  Variance 

2390873.19 

0.16 

0.15 

0.01 

Kurtosis 

-0.07 

-0.07 

-0.08 

0.01 

Skewness 

0.76 

0.76 

0.74 

0.02 

Range  (days) 

8696.34 

2.28 

2.05 

0.23 

Minimum  (days) 

1119.06 

0.29 

0.29 

0.01 

Maximum  (days) 

9815.40 

2.58 

2.34 

0.24 

Program  Count 

6593.00 

6593.00 

6604.00 

-11.00 

Arrive  at  MS  C 

6593.00 

1.00 

1.00 

0.00 

Table  35:  Approval  bodies  results 

This  intervention  is  not  unlike  many  of  those  seen  in  the  requirements  swim  lane.  The 


range  and  maximum  program  duration  is  affected.  Very  little  else  is  affected.  The  reasons  for  the 


changes  from  the  baseline  are  similar  if  not  identical  to  the  other  changes  mentioned. 


"Technical  Interventions" 


The  technical  intervention  described  here  refers  to  the  random  technical  uncertainty  processes 
that  exist  prior  to  MS  B  and  MS  C.  This  uncertainty  is  used  to  account  for  unknown  unknowns  in  the 
execution  of  development  contracts.  When  these  unknown  unknowns  are  encountered,  they  range  the 
gamut  from  technical  problems  that  were  not  foreseen  to  conditions  out  of  the  control  of  all  parties, 
such  as  a  natural  disaster  or  other  event  that  has  a  cost  and/or  schedule  impact  on  the  program.  This 
intervention  eliminates  all  possibility  of  this  from  happening.  It  likely  represents  the  lower  bound  of  the 
impact  of  improved  processes  relating  to  the  quality  of  the  program  going  through  the  system. 
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Exit  at  MS  C 

Baseline 

Normalized 

Baseline 

technical  interventions 

Delta 

Mean  (days) 

3806.63 

1.00 

0.97 

0.03 

Standard  Error 

19.04 

0.01 

0.00 

0.00 

Median  (days) 

3472.15 

0.91 

0.89 

0.03 

Standard  Deviation  (days) 

1546.24 

0.41 

0.39 

0.02 

Sample  Variance 

2390873.19 

0.16 

0.15 

0.02 

Kurtosis 

-0.07 

-0.07 

-0.19 

0.12 

Skewness 

0.76 

0.76 

0.72 

0.04 

Range  (days) 

8696.34 

2.28 

1.99 

0.29 

Minimum  (days) 

1119.06 

0.29 

0.29 

0.01 

Maximum  (days) 

9815.40 

2.58 

2.28 

0.30 

Program  Count 

6593.00 

6593.00 

6615.00 

-22.00 

Arrive  at  MS  C 

6593.00 

1.00 

1.00 

0.00 

Table  36:  Technical  Interventions  Results 

This  intervention  not  only  affected  the  mean  time  through  the  system,  e.g.  improved  it  by  3%, 
but  also  reduced  the  range  by  a  factor  of  0.3,  considerably  more  than  other  interventions  and  similar  to 
the  change  wrought  by  the  funding  instability  intervention.  The  change  in  the  kurtosis  indicates  a  more 
rounded  peak  and  shorter  thinner  tails  due  to  frequent,  modestly-sized  deviations.  In  other  words,  this 
intervention  affected  those  programs  that  otherwise  would  have  been  considered  "problematic"  and 
are  near  the  maximum  end  of  the  spectrum  of  program  durations.  These  problematic  programs  are  the 
ones  that  not  only  have  the  unexpected  technical  issues  arise  during  the  execution  of  the  program— 
which  have  been  eliminated  by  this  intervention— but  also  are  those  that  deal  with  budget  cuts 
continually  and  other  issues  not  related  to  the  unknown  and  unexpected  technical  issues. 

"PDR  Intervention" 


This  intervention  eliminated  any  probability  of  failing  the  Preliminary  Design  Review.  The 
nearest  demonstration  of  this  outcome  in  reality  would  be  due  to  the  quality  of  the  processes  and  the 
program  itself  increasing  considerably.  This  represents  the  lower  bound  of  possible  distribution 
outcomes.  It  is  a  lower  bound  because  it  is  the  best  improvement  that  is  possible  while  in  reality  there 
will  always  be  some  probability  of  failing  PDR. 
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Exit  at  MS  C 

Baseline 

Normalized 

Baseline 

PDR  Intervention 

Delta 

Mean  (days) 

3806.63 

1.00 

0.99 

0.01 

Standard  Error 

19.04 

0.01 

0.00 

0.00 

Median  (days) 

3472.15 

0.91 

0.91 

0.01 

Standard  Deviation  (days) 

1546.24 

0.41 

0.40 

0.00 

Sample  Variance 

2390873.19 

0.16 

0.16 

0.00 

Kurtosis 

-0.07 

-0.07 

-0.12 

0.05 

Skewness 

0.76 

0.76 

0.74 

0.02 

Range  (days) 

8696.34 

2.28 

2.14 

0.15 

Minimum  (days) 

1119.06 

0.29 

0.30 

0.00 

Maximum  (days) 

9815.40 

2.58 

2.43 

0.15 

Program  Count 

6593.00 

6593.00 

6594.00 

-1.00 

Arrive  at  MS  C 

6593.00 

1.00 

1.00 

0.00 

Table  37:  PDR  intervention  results 

This  intervention  had  a  significant  impact  on  those  programs  that  otherwise  would  have  failed 
one  or  two  PDRs  and  finally  being  successful.  Therefore  it  affects  the  range  and  maximum  of  the 
distributions  the  most.  The  model  shows  that  this  intervention  is  best  suited  for  programs  that  normally 
would  have  been  plagued  by  quality  problems. 

"CDR  Intervention" 


The  Critical  Design  Review  intervention  is  identical  to  the  PDR  one  in  that  the  intervention  made 
was  to  reduce  the  probability  of  failure  at  this  step  to  zero.  Again  this  would  be  a  quality  intervention. 
The  results  follow. 
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Exit  at  MS  C 

Baseline 

Normalized 

Baseline 

CDR  intervention 

Delta 

Mean  (days) 

3806.63 

1.00 

0.98 

0.02 

Standard  Error 

19.04 

0.01 

0.00 

0.00 

Median  (days) 

3472.15 

0.91 

0.90 

0.01 

Standard  Deviation  (days) 

1546.24 

0.41 

0.39 

0.02 

Sample  Variance 

2390873.19 

0.16 

0.15 

0.01 

Kurtosis 

-0.07 

-0.07 

-0.15 

0.08 

Skewness 

0.76 

0.76 

0.72 

0.03 

Range  (days) 

8696.34 

2.28 

2.10 

0.19 

Minimum  (days) 

1119.06 

0.29 

0.29 

0.00 

Maximum  (days) 

9815.40 

2.58 

2.39 

0.19 

Program  Count 

6593.00 

6593.00 

6605.00 

-12.00 

Arrive  at  MS  C 

6593.00 

1.00 

1.00 

0.00 

Table  38:  CDR  Intervention 

This  intervention  had  a  significant  impact  on  those  programs  that  otherwise  would  have  failed 
one  or  two  CDRs  until  finally  being  successful.  Therefore  it  affects  the  range  and  maximum  of  the 
distributions  the  most.  The  model  shows  that  this  intervention  is  best  suited  for  programs  that  normally 
would  have  been  plagued  by  quality  problems. 

"DRR  Intervention" 


The  Intervention  at  the  Design  Readiness  Review  point  is  similar  to  the  PDR  and  CDR 


interventions  reflecting  quality  improvements. 


Normalized 


Exit  at  MS  C 

Baseline 

Baseline 

DRR 

Delta 

Mean  (days) 

3806.63 

1.00 

1.00 

0.00 

Standard  Error 

19.04 

0.01 

0.00 

0.00 

Median  (days) 

3472.15 

0.91 

0.91 

0.00 

Standard  Deviation  (days) 

1546.24 

0.41 

0.41 

0.00 

Sample  Variance 

2390873.19 

0.16 

0.16 

0.00 

Kurtosis 

-0.07 

-0.07 

-0.07 

0.00 

Skewness 

0.76 

0.76 

0.76 

-0.01 

Range  (days) 

8696.34 

2.28 

2.28 

0.00 

Minimum  (days) 

1119.06 

0.29 

0.29 

0.00 

Maximum  (days) 

9815.40 

2.58 

2.58 

0.00 

Program  Count 

6593.00 

6593.00 

6611.00 

-18.00 

Arrive  at  MS  C 

6593.00 

1.00 

1.00 

0.00 

Table  39:  DRR  Intervention 


188 


The  DRR  intervention  did  not  have  an  appreciable  impact  on  any  aspect  of  the  program 


characteristics  or  distribution  data. 

"TRR  Intervention" 

The  Test  Readiness  Review  is  an  essential  part  of  any  program  and  this  intervention  was  to 
assess  the  impact  of  increasing  the  quality  of  the  program  such  that  there  was  zero  probability  of  failing 
this  review.  The  results  follow. 


Normalized 


Exit  at  MS  C 

Baseline 

Baseline 

TRR 

Delta 

Mean  (days) 

3806.63 

1.00 

0.99 

0.01 

Standard  Error 

19.04 

0.01 

0.00 

0.00 

Median  (days) 

3472.15 

0.91 

0.90 

0.01 

Standard  Deviation  (days) 

1546.24 

0.41 

0.41 

0.00 

Sample  Variance 

2390873.19 

0.16 

0.16 

0.00 

Kurtosis 

-0.07 

-0.07 

-0.06 

-0.01 

Skewness 

0.76 

0.76 

0.77 

-0.01 

Range  (days) 

8696.34 

2.28 

2.28 

0.00 

Minimum  (days) 

1119.06 

0.29 

0.29 

0.00 

Maximum  (days) 

9815.40 

2.58 

2.58 

0.00 

Program  Count 

6593.00 

6593.00 

6608.00 

-15.00 

Arrive  at  MS  C 

6593.00 

1.00 

1.00 

0.00 

Table  40:  TRR  Intervention  Results 

This  particular  activity  does  not  seem  to  have  an  appreciable  impact  on  the  performance  of  the 


model.  This  outcome  is  somewhat  surprising  since  testing  and  scheduling  of  test  ranges  was  raised  in 


the  discussion  with  various  interviewees  as  an  area  of  concern.  This  issue  will  be  looked  at  for  future 


work. 


"Test  trades  intervention" 


Following  testing  activities,  there  is  some  probability  that  additional  engineering  would  need  to 


be  done  and  "trades"  made  to  adapt  the  program  to  address  the  results  of  the  last  series  of  tests. 


Testing  is  an  area  that  was  identified  as  one  that  could  be  very  problematic  through  the  various 


interviews.  Many  people  and  studies  had  pointed  to  issues  dealing  with  test,  from  problems  ranging 
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from  securing  test  range  facilities  to  large  amounts  of  rework  to  fix  uncovered  problems.  An 
intervention  here  eliminates  any  probability  that  testing  would  uncover  any  technical  issues  requiring 
additional  work  or  test  range  time.  This  intervention  falls  within  the  "quality"  category  as  improving  the 
overall  quality  of  programs  in  the  system  would  decrease  the  likelihood  of  needing  to  make  additional 
technical  trades  after  testing.  The  results  of  the  intervention  are  shown  below. 


Normalized 


Exit  at  MS  C 

Baseline 

Baseline 

test  trades 

Delta 

Mean  (days) 

3806.63 

1.00 

0.99 

0.01 

Standard  Error 

19.04 

0.01 

0.00 

0.00 

Median  (days) 

3472.15 

0.91 

0.90 

0.01 

Standard  Deviation  (days) 

1546.24 

0.41 

0.41 

0.00 

Sample  Variance 

2390873.19 

0.16 

0.16 

0.00 

Kurtosis 

-0.07 

-0.07 

-0.06 

0.00 

Skewness 

0.76 

0.76 

0.76 

-0.01 

Range  (days) 

8696.34 

2.28 

2.24 

0.05 

Minimum  (days) 

1119.06 

0.29 

0.30 

0.00 

Maximum  (days) 

9815.40 

2.58 

2.53 

0.05 

Program  Count 

6593.00 

6593.00 

6567.00 

26.00 

Arrive  at  MS  C 

6593.00 

1.00 

1.00 

0.00 

Table  41:  Test  trades  intervention  results 

It  appears  that  only  programs  that  run  into  "problems"  or  those  programs  comprising  the 
"maximum"  of  the  range  of  outcomes  is  positively  affected  by  this  intervention.  Improving  this  process, 
with  respect  to  improving  availability  of  test  ranges,  does  not  seem  to  provide  a  large  return  compared 
to  some  of  the  other  interventions.  However,  if  the  program  is  extremely  large,  complex  and  expensive, 
having  slack  in  the  availability  of  test  ranges  may  prove  to  be  worthwhile.  Future  work  would  have  to 
determine  the  circumstances  where  the  cost/benefit  analysis  would  prove  beneficial. 

"SVR  Intervention" 


The  System  Verification  Review  is  the  final  culminating  review  prior  to  MS  C  and  failure  of  this 
review  should  have  significant  results.  Like  the  TRR,  the  SVR  probability  of  failure  was  eliminated, 
suggesting  great  quality  in  the  programs  meeting  this  review. 
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Exit  at  MS  C 

Normalized 
Baseline  Baseline 

SVR 

Delta 

Mean  (days) 

3806.63 

1.00 

1.00 

0.00 

Standard  Error 

19.04 

0.01 

0.00 

0.00 

Median  (days) 

3472.15 

0.91 

0.91 

0.00 

Standard  Deviation  (days) 

1546.24 

0.41 

0.41 

0.00 

Sample  Variance 

2390873.19 

0.16 

0.16 

0.00 

Kurtosis 

-0.07 

-0.07 

-0.08 

0.01 

Skewness 

0.76 

0.76 

0.75 

0.00 

Range  (days) 

8696.34 

2.28 

2.28 

0.00 

Minimum  (days) 

1119.06 

0.29 

0.29 

0.00 

Maximum  (days) 

9815.40 

2.58 

2.58 

0.00 

Program  Count 

6593.00 

6593.00 

6591.00 

2.00 

Arrive  at  MS  C 

6593.00 

1.00 

1.00 

0.00 

Table  42:  SVR  Intervention 

Like  the  TRR  intervention,  the  SVR  results  show  no  appreciable  impact  to  the  outcomes 
of  the  model  distribution.  Equally,  this  is  a  surprise  that  will  be  reserved  for  future  work.  However,  it 
can  be  explained  that  by  the  time  a  program  reaches  this  point  in  the  development,  so  much  "history" 
already  exists  in  the  program  that  any  delays  encountered  at  this  point  are  negligible  compared  to  the 
total  program  baseline. 


Other  combinations 

"Systems  Engineering  Intervention" 

This  intervention  is  the  combination  of  all  of  the  systems  engineering  type  interventions 
previously  discussed,  e.g.  PDR,  CDR,  DRR,  TRR,  SVR.  This  intervention  is  probably  a  better 
representation  of  quality  improvements  to  any  program  as  good  quality  from  the  beginning  would 
propagate  throughout  the  entire  system.  The  results  follow. 
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Exit  at  MS  C 

Baseline 

Normalized 

Baseline 

SE 

Delta 

Mean  (days) 

3806.63 

1.00 

0.93 

0.07 

Standard  Error 

19.04 

0.01 

0.00 

0.00 

Median  (days) 

3472.15 

0.91 

0.85 

0.06 

Standard  Deviation  (days) 

1546.24 

0.41 

0.37 

0.04 

Sample  Variance 

2390873.19 

0.16 

0.14 

0.03 

Kurtosis 

-0.07 

-0.07 

-0.35 

0.28 

Skewness 

0.76 

0.76 

0.67 

0.09 

Range  (days) 

8696.34 

2.28 

1.76 

0.52 

Minimum  (days) 

1119.06 

0.29 

0.29 

0.00 

Maximum  (days) 

9815.40 

2.58 

2.05 

0.52 

Program  Count 

6593.00 

6593.00 

6632.00 

-39.00 

Arrive  at  MS  C 

6593.00 

1.00 

1.01 

-0.01 

Table  43:  Systems  Enginering  Interventions 

While  most  of  the  Systems  Engineering  interventions  did  not  have  much  of  an 
appreciable  impact,  the  totality  of  all  SE  improvements  showed  improvements  in  many  areas.  First  the 
mean  of  the  programs  was  reduced  by  7%.  The  range  of  outcomes  was  reduced  from  nearly  2.5  times 
the  mean  to  only  about  2  times  the  mean.  The  distribution  itself  was  marked  by  a  sharper  peak,  and 
longer  fatter  tails  due  to  infrequent,  extreme  deviations  as  well  as  the  skew  becoming  less  pronounced. 
Clearly  improving  these  processes  or  improving  the  quality  of  the  overall  system  was  manifested  in 
these  results.  While  they  represent  the  theoretical  "lower  bound",  Systems  Engineering  done  well  does 
make  a  substantial  difference,  especially  with  those  programs  that  otherwise  would  have  been 
"problematic." 

"SE  &  Acquisition  Kill  Interventions" 

Coupling  the  above  intervention  with  the  Acquisition  Kill  intervention  should  provide  some 
interesting  results  based  upon  the  stand-alone  versions. 
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Exit  at  MS  C 

Baseline 

Normalized 

Baseline 

SE  and  Acquisition 

Delta 

Mean  (days) 

3806.63 

1.00 

0.84 

0.16 

Standard  Error 

19.04 

0.01 

0.01 

0.00 

Median  (days) 

3472.15 

0.91 

0.74 

0.17 

Standard  Deviation  (days) 

1546.24 

0.41 

0.34 

0.07 

Sample  Variance 

2390873.19 

0.16 

0.12 

0.05 

Kurtosis 

-0.07 

-0.07 

0.92 

-0.99 

Skewness 

0.76 

0.76 

1.16 

-0.41 

Range  (days) 

8696.34 

2.28 

1.76 

0.52 

Minimum  (days) 

1119.06 

0.29 

0.29 

0.00 

Maximum  (days) 

9815.40 

2.58 

2.05 

0.53 

Program  Count 

6593.00 

6593.00 

3572.00 

3021.00 

Arrive  at  MS  C 

6593.00 

1.00 

0.54 

0.46 

Table  44:  SE  and  Acquisition  Kill  Intervention  Results 

This  intervention  shows  a  great  deal  of  reductions  across  the  board.  The  reasons  for  the 
changes  remain  the  same  for  both  the  SE  intervention  and  the  Acquisition  Kill  intervention  discussed 
earlier  and  these  effects  seem  to  be  merely  additive.  There  is  little  evidence  of  unique  coupling 
interactions  in  the  data  outcome  distribution. 


"MAJCOM  &  Acquisition  approval  bodies  intervention" 

Using  a  combination  of  these  two  previously  tried  interventions  will  also  explore  the  interaction 
of  these  interventions,  if  any,  and  determine  how  these  change  the  outcomes  of  the  model  results. 
These  two  particular  interventions  were  chosen  to  try  since  they  both  deal  with  eliminating  calendar 
delays.  The  practical  interpretation  is  that  the  DOD  will  improve  the  capacity,  e.g.  manning,  of  both 
JCIDS  and  Acquisition  sufficiently  so  that  there  is  no  need  for  any  delay  or  waiting  time.  The  results 
follow. 


193 


Exit  at  MS  C 

Baseline 

Normalized 

Baseline 

approval  bodies  and  MAJCOM 

Delta 

Mean  (days) 

3806.63 

1.00 

0.97 

0.03 

Standard  Error 

19.04 

0.01 

0.00 

0.00 

Median  (days) 

3472.15 

0.91 

0.90 

0.02 

Standard  Deviation  (days) 

1546.24 

0.41 

0.38 

0.02 

Sample  Variance 

2390873.19 

0.16 

0.15 

0.02 

Kurtosis 

-0.07 

-0.07 

-0.01 

-0.06 

Skewness 

0.76 

0.76 

0.76 

0.00 

Range  (days) 

8696.34 

2.28 

2.06 

0.23 

Minimum  (days) 

1119.06 

0.29 

0.28 

0.01 

Maximum  (days) 

9815.40 

2.58 

2.34 

0.24 

Program  Count 

6593.00 

6593.00 

6558.00 

35.00 

Arrive  at  MS  C 

6593.00 

1.00 

0.99 

0.01 

Table  45:  MAJCOM  and  Acquisition  approval  bodies  intervention  results 

The  combination  of  these  two  interventions  only  shows  an  additive  contribution  regarding  the 
mean  and  kurtosis  of  the  baseline  program  outcome  distribution.  However,  the  range  and  maximum 
are  not  additive  -  they  are  the  same.  The  implications  for  this  result  is  that  while  standing  alone  they 
appear  to  be  on  the  critical  path,  together  these  interventions  only  have  a  significant  effect  upon  those 
programs  that  go  through  the  entire  acquisition  system  and  therefore  are  exposed  to  more 
"opportunities"  of  encountering  these  kinds  of  processes. 

"Funding  and  technical  uncertainty  intervention" 

A  combination  of  these  two  interventions  was  chosen  because  it  represented  two  of  the  most 
commented  areas  of  frustration  among  participants  in  the  overall  system.  It  also  seems  reasonable  that 
any  intervention  taken  on  a  large  scale  would  address  portions  of  these  issues.  The  following  table 
shows  the  results  of  this  intervention  strategy. 
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Exit  at  MS  C 

Baseline 

Normalized 

Baseline 

funding  and  technical 

Delta 

Mean  (days) 

3806.63 

1.00 

0.93 

0.07 

Standard  Error 

19.04 

0.01 

0.00 

0.00 

Median  (days) 

3472.15 

0.91 

0.86 

0.05 

Standard  Deviation  (days) 

1546.24 

0.41 

0.36 

0.04 

Sample  Variance 

2390873.19 

0.16 

0.13 

0.03 

Kurtosis 

-0.07 

-0.07 

-0.36 

0.29 

Skewness 

0.76 

0.76 

0.63 

0.12 

Range  (days) 

8696.34 

2.28 

1.73 

0.56 

Minimum  (days) 

1119.06 

0.29 

0.30 

0.00 

Maximum  (days) 

9815.40 

2.58 

2.03 

0.55 

Program  Count 

6593.00 

6593.00 

6566.00 

27.00 

Arrive  at  MS  C 

6593.00 

1.00 

1.00 

0.00 

Table  46:  Funding  and  Technical  Uncertainty  Intervention  Results 

These  results  were  also  surprising.  It  was  expected  that  these  two  interventions  combined 


would  have  a  much  greater  impact  on  the  overall  mean  of  the  program  outcomes.  Interestingly,  only 


the  mean  and  the  skewness  results  were  cumulative  in  their  affect  on  outcomes  versus  the  normalized 


baseline.  However,  the  kurtosis,  range,  and  maximum  are  not.  Still,  a  0.56  factor  reduction  in  the  range 
of  the  system  is  significant  and  speaks  to  the  effect  that  these  interventions  have  on  those  programs 
that  go  through  the  entire  baseline.  The  other  programs  that  skip  and  circumvent  portions  of  the 
system  do  not  experience  these  interventions  as  much.  This  explains  why  the  mean  of  the  experimental 
outcome  is  not  affected  as  much. 

"Random  Eight  intervention" 

The  Random  Eight  intervention  is  named  from  the  random  combination  of  previously  tried 
strategies  into  a  single  intervention.  These  eight  interventions  are:  funding  stability,  acquisition 
termination  points,  technical  uncertainty,  acquisition  approval  bodies,  CDR,  MAJCOM  approval  bodies, 
PDR,  and  air  staff  process  interventions.  The  purpose  of  this  combined  intervention  is  to  determine  how 
a  random  combination  affects  the  outcome  of  the  model. 
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Exit  at  MS  C 

Baseline 

Normalized 

Baseline 

top  8  intervention 

Delta 

Mean  (days) 

3806.63 

1.00 

0.83 

0.17 

Standard  Error 

19.04 

0.01 

0.01 

0.00 

Median  (days) 

3472.15 

0.91 

0.76 

0.15 

Standard  Deviation  (days) 

1546.24 

0.41 

0.32 

0.09 

Sample  Variance 

2390873.19 

0.16 

0.10 

0.06 

Kurtosis 

-0.07 

-0.07 

0.54 

-0.61 

Skewness 

0.76 

0.76 

1.01 

-0.25 

Range  (days) 

8696.34 

2.28 

1.64 

0.65 

Minimum  (days) 

1119.06 

0.29 

0.29 

0.00 

Maximum  (days) 

9815.40 

2.58 

1.93 

0.65 

Program  Count 

6593.00 

6593.00 

3555.00 

3038.00 

Arrive  at  MS  C 

6593.00 

1.00 

0.54 

0.46 

Table  47:  Random  Eight  Intervention  results 

These  interventions  together  show  significant  impacts  across  almost  every  measure  compared 
to  the  baseline  case.  A  seventeen  percent  reduction  in  the  overall  mean  of  programs  going  through  the 
system  is  significant.  Furthermore,  reducing  the  maximum  outcome  from  about  two  and  one  half  times 
the  baseline  mean  to  less  than  two  times  the  baseline  mean  is  a  significant  reduction.  Furthermore, 
with  the  drop  in  the  mean  outcome,  it  is  the  handful  of  "problem"  programs  that  drive  the  large  skew  to 
the  right.  All  other  measures  point  to  improvements  from  the  baseline,  assuming  less  time  and  variance 
is  "better." 


This  outcome  speaks  to  the  value  of  continuous  improvement.  There  is  room  for  it  to  occur  in 


the  existing  system.  The  larger  question  that  this  outcome  raises  is  what  the  "cost"  to  achieve  these 


improvements  is.  Are  there  other  interventions  that  when  combined  would  achieve  nearly  as 


impressive  improvements  as  this  one? 


Greatest  Impact  Interventions 

This  section  looks  at  the  impacts  of  those  interventions  that  had  the  greatest  impacts  overall. 
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"Top  Three  Intervention" 


Looking  at  all  of  the  individual  interventions,  the  three  interventions  that  contributed  to  the 


largest  reduction  in  the  mean  versus  the  baseline  were  selected  for  this  intervention.  These  three  were 


funding  stability,  acquisition  kill  points,  and  technical  uncertainty.  The  following  table  shows  the  results 


of  this  combination. 


Normalized 


Exit  at  MS  C 

Baseline 

Baseline 

top  3  intervention 

Delta 

Mean  (days) 

3806.63 

1.00 

0.85 

0.15 

Standard  Error 

19.04 

0.01 

0.01 

0.00 

Median  (days) 

3472.15 

0.91 

0.76 

0.15 

Standard  Deviation  (days) 

1546.24 

0.41 

0.34 

0.06 

Sample  Variance 

2390873.19 

0.16 

0.12 

0.05 

Kurtosis 

-0.07 

-0.07 

0.66 

-0.73 

Skewness 

0.76 

0.76 

1.08 

-0.33 

Range  (days) 

8696.34 

2.28 

1.79 

0.50 

Minimum  (days) 

1119.06 

0.29 

0.30 

0.00 

Maximum  (days) 

9815.40 

2.58 

2.09 

0.49 

Program  Count 

6593.00 

6593.00 

3535.00 

3058.00 

Arrive  at  MS  C 

6593.00 

1.00 

0.54 

0.46 

Table  48:  Top  Three  Interventions  Results 

The  results  of  this  intervention  show  all  of  the  similar  improvements  that  the  Random  Eight 
Intervention  did,  but  the  improvements  were  not  to  the  same  degree.  Still,  the  3%  difference  in  means 
between  interventions  of  the  eight  randomly  chosen  ones  and  this  intervention  show  that  some 
interventions  are  worth  more  than  others.  It  also  underscores  the  fact  that  some  interventions  will  be 


far  more  costly  than  others  to  implement.  Therefore,  careful  analysis  and  weighing  of  alternatives 


should  be  done  before  making  any  changes  to  the  system. 


" All  interventions" 


Having  tested  various  combinations,  this  intervention  seeks  to  determine  what  the  impact  of  all 


of  the  individual  interventions,  when  combined,  would  be.  While  implementation  of  all  of  these 
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interventions  is  probably  not  realistic,  the  results  would  certainly  represent  the  "lower  bound"  of  all 


possible  improvements  that  could  be  made  to  the  system. 


Normalized 


Exit  at  MS  C 

Baseline 

Baseline 

All  interventions 

Delta 

Mean  (days) 

3806.63 

1.00 

0.81 

0.19 

Standard  Error 

19.04 

0.01 

0.01 

0.00 

Median  (days) 

3472.15 

0.91 

0.73 

0.18 

Standard  Deviation  (days) 

1546.24 

0.41 

0.32 

0.09 

Sample  Variance 

2390873.19 

0.16 

0.10 

0.06 

Kurtosis 

-0.07 

-0.07 

0.65 

-0.72 

Skewness 

0.76 

0.76 

1.05 

-0.30 

Range  (days) 

8696.34 

2.28 

1.60 

0.68 

Minimum  (days) 

1119.06 

0.29 

0.28 

0.01 

Maximum  (days) 

9815.40 

2.58 

1.88 

0.69 

Program  Count 

6593.00 

6593.00 

3544.00 

3049.00 

Arrive  at  MS  C 

6593.00 

1.00 

0.54 

0.46 

Table  49:  All  Interventions  combined  results 

These  results  show  that  combining  all  of  the  previously  tested  interventions  results  in  a  19% 
reduction  of  the  mean  of  all  programs  going  through  the  system  when  compared  to  the  baseline  case. 
Furthermore,  the  range  and  maximum  outcomes  are  significantly  reduced  from  the  baseline  case  with 
the  maximum  only  1.88  times  the  mean  of  the  baseline  case.  It  is  also  likely  that  these  are  very 
conservative  results.  A  potential  consequence  of  the  sheer  number  of  programs  in  the  system  being 
reduced  might  also  bring  with  it  additional  process  effects  that  reduce  the  overall  time  required  for 
individual  process  steps  to  be  accomplished  since  they  are  not  "saturated"  or  operating  at  or  near 


capacity. 


Final  Analysis  and  Conclusions 

Looking  only  at  specific  aspects  of  the  interventions,  some  patterns  emerge  that  are  worth 
discussion.  First,  a  look  at  the  greatest  impacts  on  the  mean  outcome  by  intervention  type  will  be  taken 


followed  by  looks  at  other  outcome  descriptors. 
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Mean  outcome:  in  order  of  impact  compared  to  baseline  1.0  (value  /  percent  reduction) 


All  interventions 

(0.81  /  19%) 

Eight  random  interventions 

(0.83  /  17%) 

SE  and  Acquisition  termination 

(0.84/16%) 

"Top  three" 

(0.85  /  15%) 

Acquisition  termination 

(0.91  /  9%) 

SE  /  funding  stability  and  technical  uncertainty  (tie) 

(0.93  /  7%) 

Funding  stability 

(0.96  /  4%) 

Technical  uncertainty 

(0.97  /  3%) 

Median  outcome:  in  order  of  impact  compared  to  baseline  0.91  (value/percent  reduction) 


All  interventions 

(0.73/ 

SE  and  Acquisition  termination 

(0.74/ 

Top  three  /  eight  random  interventions  (tie) 

(0.76/ 

Acquisition  termination 

(0.81/ 

Systems  Engineering 

(0.85/ 

Funding  stability  and  technical  uncertainty 

(0.86/ 

Funding  stability 

(0.88/ 

Technical  uncertainty 

(0.89/ 

Maximum  outcome:  greatest  impact  in  reduction  compared  to  baseline  value  (2.58) 

All  interventions  (1.88/27.1%) 

Eight  random  interventions  (1.93  /  25.2%) 

Funding  stability  and  technical  uncertainty  (2.03  /  21.2%) 

Systems  Engineering  /  SE  &  Acquisition  termination  (tie)  (2.05  /  20.5%) 
Top  three  (2.09/19.0%) 

Funding  stability  (2.12/17.8%) 

Technical  uncertainty  (2.28  /  11.6%) 

Range  outcome:  Greatest  impact  in  reduction  of  range  from  baseline  value  (2.28) 

All  interventions  (1.60  /  29.8%) 

Eight  random  interventions  (1.64  /  28%) 

Funding  stability  and  technical  uncertainty  (1.73  /  24%) 

Systems  Engineering  /  SE  &  Acquisition  termination  (tie)  (1.76  /  22.8%) 
Top  three  (1.79/21.5%) 

Funding  stability  (1.83/19.7%) 

Technical  uncertainty  (1.99  /  12.7%) 


Skewness  outcome:  Larger  right  tail  in  distribution  than  baseline  value  (0.76) 
Acquisition  termination  (1.2) 

SE  and  Acquisition  termination  (1-16) 

Top  three  (1.08) 
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All  interventions  (1-05) 

Eight  random  interventions  (1.01) 

Smaller  right  tail  in  distribution  than  baseline  (0.76) 

Funding  stability  and  technical  uncertainty  (0.63) 

Systems  engineering  (0.67) 

Funding  stability  (0.66) 


Kurtosis  outcome:  Higher  number  (sharper  peak,  longer  fatter  tails  due  to  infrequent,  extreme 


deviations) 

Acquisition  termination  (1.19) 

SE  and  Acquisition  termination  (0.93) 

Top  three  (0.66) 

All  interventions  (0.65) 

Eight  random  interventions  (0.54) 

Smaller  number  (more  rounded  peak  and  shorter  thinner  tails  due  to  frequent, 
modestly-sized  deviations) 

Funding  stability  and  technical  uncertainty  (-0.36) 

Systems  Engineering  (-0.35) 

Funding  stability  (-0.30) 

Technical  uncertainty  (-0.19) 

CDR  (-0.15) 


Taking  a  broader  look  at  all  of  the  interventions  and  their  outcomes,  generally  three  types  of 
effects  were  noted.  These  effects  were  seen  in:  the  average  time  for  a  program  to  reach  MS  C;  the 
distribution  characteristics  of  programs  reaching  MS  C,  e.g.  skew,  kurtosis,  range;  and  the  total  number 
of  programs  reaching  MS  C. 

Regarding  the  first  effect,  if  total  time  to  MS  C  is  valued,  multiple  interventions  will  be  required 
for  the  largest  effect.  The  "best"  experimental  data  outcomes  were  composed  of  multiple  interventions 
while  the  "best"  postulated  improvement  is  nearly  20%  less  than  current  baseline  mean  duration. 
However,  the  actual  improvement  if  these  interventions  are  implemented  is  likely  much  less  than 
experimental  data  results. 

Regarding  the  second  effect,  if  "predictability"  or  minimizing  variance  across  programs  is  valued, 
then  the  interventions  favored  by  the  experimental  data  are  somewhat  different.  Those  seen  to  be 
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most  promising  consist  of  "quality"  interventions  such  as:  reducing  funding  instability,  reducing 
technical  uncertainty,  and  improving  SE  processes.  These  interventions  will  be  among  the  most  difficult 
to  implement,  maintain  and  measure  during  the  existence  of  a  typical  program. 

Regarding  the  third  effect,  if  process  throughput  and  capacity  of  the  overall  system  are  valued, 
then  interventions  that  increase  the  probability  of  program  being  terminated  should  be  implemented. 
From  the  experimental  interventions,  only  one  intervention  substantially  impacted  the  total  count  of 
programs  arriving  at  MS  C:  increasing  the  probability  of  a  program  being  killed  at  major  milestone  and 
other  reviews  (Acquisition  termination).  Interventions  like  these  address  some  of  the  "portfolio" 
capabilities  that  could  be  wielded  by  individuals  at  these  process  points.  These  capabilities  would  add 
additional  "portfolio  effects"  which  are  currently  not  addressed  in  the  model.  For  instance,  processes 
operating  at  or  near  saturation  levels  would  decrease;  their  efficiency  would  likely  increase  and 
timeliness  would  likely  decrease;  and  some  of  the  other  instabilities  present  in  the  system  would  be 
reduced. 

There  is  NO  silver  bullet  for  dramatic  system  improvements.  Intertwined  processes  invoke 
emergent  behaviors  that  are  not  easily  controlled  by  specific  interventions.  Acquisition  termination 
capabilities  are  desirable  but  not  likely  given  acquisition  authority  is  limited.  The  experimental 
intervention  settings  are  contrived,  e.g.  it  is  not  realistic  that  50%  of  all  decisions  will  terminate 
programs.  Funding  stability  is  a  laudable  goal  but  is  not  realistic  with  the  current  PPBE  configuration; 
e.g.  zero-sum  budgeting,  "savings"  not  accrued  but  used  for  other  demands;  demand  exceeds  supply. 
The  technical  uncertainty  intervention  is  not  possible  to  be  eliminated,  but  many  quality  interventions 
will  have  largest  impacts.  Counting  on  increased  success  at  PDR  and  CDR  is  theoretically  possible  due  to 
the  increased  emphasis  by  the  DOD  on  Systems  Engineering,  but  is  not  guaranteed.  Eliminating 
processes  will  reduce  time  in  the  system  but  it  also  suggests  a  strong  need  to  determine  the  value  added 
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by  existing  process  steps.  Are  they  really  worth  the  time  and  effort?  Is  the  payoff  commensurate  with 


the  investment? 

In  closing,  the  model  of  the  overall  acquisition  system  has  fulfilled  its  purposes  and  has  allowed 
the  main  hypothesis  of  many  well  thought  out  interventions  to  be  tested.  Significant  insight  has  been 
gained  into  the  system's  behavior  through  the  application  of  these  various  interventions.  Certainly 
there  are  other  interventions  that  can  be  tested,  but  the  analysis  above  represents  a  reasonable  set  of 
potential  interventions  as  well  as  those  designed  to  probe  the  workings  of  the  model.  The  closing 
chapter  will  address  these  and  other  significant  findings  made  in  the  course  of  this  research. 
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CHAPTER  9  --  CONCLUSIONS  AND  SUMMARY 

The  overarching  theme  and  motivation  for  this  work  has  been  to  better  understand  the 
operation  of  the  big  "A"  of  acquisition.  This  large  system  has  so  many  moving  parts  and  is  so  full  of 
complexity  that  other  approaches  and  attempts  to  identify  and  characterize  many  of  the  drivers  of  the 
system  have  fallen  short.  This  work  also  does  not  purport  to  be  or  present  the  defining  answer  for  all  of 
the  systems'  woes.  However,  it  does  shed  new  insight  and  provide  a  different  mechanism  to  look  at  the 
behaviors  of  the  overall  system  as  well  as  provide  an  opportunity  to  selectively  test  different 
interventions  and  analyze  those  outcomes.  This  work  has  collectively  tried  to  approach  the  problem 
from  both  a  qualitative  as  well  as  a  quantitative  standpoint,  trying  to  find  a  balance  between  the  way 
the  system  should  work  and  the  way  that  it  really  does  work.  It  has  also  sought  to  capture  the  concerns 
of  the  people  working  within  the  system  as  well  as  the  constraints  imposed  by  the  system. 

Nevertheless,  this  is  the  first  time  that  the  overall  acquisition  system  has  been  modeled  in  this 
fashion.  According  to  a  retired  Air  Force  civilian,  with  an  extensive  background  in  the  acquisition 
system,  when  presented  with  some  of  the  results  from  the  model,  felt  that  this  effort  represented  the 
first  successful  "model"  of  the  entire  enterprise.  He  explained  how  it  bears  resemblance  to  a  failed 
effort  led  by  the  Air  Force  in  the  1980s,  which  was  called  the  Air  Force  Acquisition  Model.  Most  Air 
Force  professionals  are  familiar  with  the  legacy  of  this  failed  effort,  which  evolved  into  the  Air  Force 
Acquisition  Desk  Book  and  later  to  the  online  Air  Force  Acquisition  Knowledge  Sharing  System.  The 
legacy  system  today  is  merely  a  collection  of  best  practices,  vignettes,  and  working  knowledge  obtained 
and  shared  by  other  acquisition  professionals. 

Qualitative  Observations 

The  following  observations  are  qualitative  in  that  they  are  not  substantiated  through  the  output 
of  the  model  representing  the  acquisition  enterprise.  However,  these  observations  tend  to  provide 
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additional  context  to  the  more  quantitative  research  stemming  from  the  output  of  the  model.  They 
represent  an  expression  of  the  various  people  interviewed  throughout  the  course  of  this  research  effort. 
Furthermore,  these  observations  often  did  not  surface  until  after  both  qualitative  studies,  e.g.  the  two 
separate  interview  efforts,  were  completed  and  analyzed.  Some  required  the  additional  insights  gained 
during  some  of  the  validation  activities  to  emerge. 

Observation  No.  1:  Portfolio  management  for  acquisition  is  not  an  appropriate  metaphor  to  use 
to  describe  the  management  and  operation  of  the  Acquisition  system.  Initially,  a  great  deal  of  effort 
was  made  into  understanding  the  way  the  system  worked.  An  assumption  and  framing  mechanism  to 
understand  the  system  was  to  examine  if  portfolio  management,  as  practiced  by  fund  managers  on  Wall 
Street,  would  be  an  appropriate  analog  to  apply  to  weapon  system  development  for  the  Department  of 
Defense.  However,  the  research  shows  this  is  not  the  case.  The  limitations  to  practicing  product 
portfolio  management  in  defense  acquisition  are  due  to  a  variety  of  factors  outside  of  the  control  of 
portfolio  managers.  Most  notably,  these  are  the  diffusion  of  responsibility  and  accountability  for 
programs  and  their  development.  Both  the  art  and  science  of  portfolio  management  lack  measures  that 
provide  meaningful  direction  to  portfolio  leaders.  Therefore,  using  portfolios  and  portfolios  of  programs 
to  manage  defense  acquisition  probably  delivers  no  advantage  other  than  streamlining  the  reporting 
and  accountability  process  back  to  Congress.  This  observation  stems  from  the  work  reported  on  in 
Chapter  3. 

Observation  No.  2:  Some  of  the  systems  aspects  to  the  overall  system  include  the  fact 
that  many  people  do  not  understand  the  workings  of  one  segment  or  swim  lane  from  another.  The 
swim  lanes  are  indeed  coupled,  but  the  understanding  of  how  they  are  coupled  is  not  well  understood. 
Most  people  understand  how  to  do  their  job  very  well,  as  well  as  how  their  job  or  process  relates  to 
processes  immediately  upstream  or  downstream  as  well  as  any  lateral  moves  into  other  swim  lanes. 
However,  understanding  of  the  overall  system  beyond  these  limited  views  is  lacking.  This  phenomenon 
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gives  rise  to  behaviors  that  seek  to  optimize  processes  and  decisions  locally  instead  of  globally.  The 
overall  system  is  full  of  actors  whose  rational  thinking,  therefore,  drives  system  behaviors  that  are  less 
than  ideal  or  optimal  from  a  system  perspective.  The  initial  observations  and  analysis  of  interview  data 
in  Chapter  3  as  well  as  some  of  the  findings  reported  in  the  section  titled  "Data  Coding  and  Analysis" 
lend  credence  to  this  observation.  Furthermore,  the  section  in  Chapter  4  titled,  "Results  and  Analysis," 
underscore  these  observations,  particularly  in  the  areas  of  "Interdependencies,"  "Money  differences  in 
acquisition  phases,"  and  "Money  drills." 

Observation  No.  3:  Risk  is  important,  but  how  it  is  important  is  becoming  lost  in  the 
details.  There  are  too  many  systemic  risks,  beyond  that  of  ordinary  program  risk  management,  that  are 
simply  not  being  addressed.  These  risks  are  cross-cutting  and  are  not  easily  characterized  with  the 
current  toolset  available  to  professionals  in  the  acquisition  system.  These  risks  deal  with  the 
organizational  and  architectural  construct  of  the  current  acquisition  system,  the  interdependencies 
between  programs,  and  the  achievement  of  national  security  goals.  Who  within  the  system  has  the 
responsibility  as  well  as  the  authority  to  deal  with  these  risks?  This  observation  was  the  key  theme  to  all 
of  Chapter  3  and  was  perpetuated  in  the  "Other  Identified  Issues"  reported  on  in  Chapter  4. 

Observation  No.  4:  The  acquisition  system  is  operating  well  beyond  its  capacity  and  does  not 
have  the  numbers  or  the  skilled  personnel  necessary  to  handle  the  workload.  Additionally,  other 
resources,  including  money,  are  constrained.  These  conditions  lead  to  classic  firefighting  behaviors  as 
reported  in  the  product  development  literature.  There  is  little,  if  any,  availability  for  more  personnel  to 
think  strategically;  rather  they  are  operating  in  a  tactical  day-to-day  mode.  One  might  argue  fewer 
programs  would  actually  translate  to  lower  demands  on  the  system,  but  this  is  far  from  certain.  Finally, 
there  is  another  component  to  the  acquisition  system  that  has  a  huge  impact  on  system  capacity  but 
was  out  of  the  scope  of  this  research:  the  sustainment  activities  that  occur  with  existing  weapon 
systems.  The  acquisition  system  and  acquisition  personnel  are  also  responsible  for  working  these 
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activities.  In  total,  the  things  that  are  measured  and  evaluated  in  the  system  are  often  tangential  to  the 


actual  job  of  delivering  a  program,  e.g.  measuring  compliance  to  training  or  mandatory  appointments, 
etc.,  and  do  not  even  attempt  to  measure  system  capacity  or  workload  issues.  These  were  clear 
messages  received  in  the  interviews  discussed  in  Chapter  3  and  ironically,  acknowledged  by  some 
interviewees  quoted  in  Chapter  4,  especially  in  the  section  entitled  "Capacity  of  the  System." 

Observation  No.  5:  The  overall  Acquisition  system  incentivizes  personnel  to  not  follow  existing 
processes  and  go  around  it.  Some  of  the  evidence  in  this  regard  is  the  proliferation  of  new  programs, 
prototypes  and  rapid  reaction  programs  that  operate  on  the  fringes  of  the  current  system.  Further, 
early  studies  are  often  not  funded  enough  to  fully  understand  and  address  new  concepts  or 
technologies,  and  program  development  timelines  remain  unrealistic  and  are  likely  very  optimistic  and 
assume  perfect  execution  of  all  aspects  of  the  system.  Interviewees  from  the  acquisition  portion  of  the 
system  saw  some  of  this  in  the  instability  of  requirements  and  priorities  they  received  as  reported  in 
Chapter  3.  Chapter  4,  however,  showed  this  to  be  a  prevailing  concept,  especially  among  those  working 
requirement  documents.  Table  6  in  Chapter  4  and  the  commentary  following  provides  a  good  snapshot 
of  the  resulting  manifestations  of  these  behaviors. 

Observation  No.  6:  The  conflict  oriented  nature  of  the  resource  allocation  process  is  a  liability  to 
acquisition  program  success.  Too  often  the  PEM  is  caught  between  competing  interests  year  after  year 
re-justifying  investments  in  programs  that  were  previously  "committed"  when  reaching  Milestone  B  and 
passing  that  "investment  decision."  "Budget  drills"  and  other  what-if  exercises  distract  strapped 
acquisition  personnel  further  from  doing  their  primary  jobs.  Interviewees  in  Chapter  3  noted  this  issue 
probably  more  than  any  other  and  Table  5  in  Chapter  4  and  the  ensuing  discussion  elaborates  on  this 
observation  further. 

Observation  No.  7:  While  programs  are  being  debated  and  traded  in  resource  allocation 
processes  individually,  there  is  a  surprising  lack  of  understanding  regarding  the  interdependencies 
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between  programs  and  the  ramifications  to  other  programs  during  these  debates.  Where  this 
information  is  known,  it  often  must  rely  upon  the  corporate  or  institutional  knowledge  possessed  by  the 
personnel  working  these  issues.  When  personnel  changes  occur,  this  knowledge  is  liable  to  be  lost.  The 
overall  complexity  of  the  resulting  system  and  its  operation  is  costly.  This  observation  was  alluded  to  in 
the  discussion  in  Chapter  3,  but  was  much  more  explicitly  address  in  the  interviews  analyzed  in  Chapter 
4.  Table  5  and  the  ensuing  discussion  goes  into  great  depth  about  the  problems  relating  to 
interdependencies. 

Observation  No.  8:  Decision  avoidance  is  preferred  across  the  overall  acquisition  system. 
Occasionally,  hard  decisions  are  wrung  out  in  some  of  the  resource  allocation  deliberations,  but  usually 
it  is  much  easier  to  defer  a  decision,  often  under  the  guise  of  preserving  flexibility.  This  is  for  all  decision 
points,  not  just  those  that  may  result  in  program  cancellation.  This  behavior  results  in  a  system  working 
beyond  its  operating  capacity,  struggling  to  deliver  each  and  every  program  it  is  working  on.  Some  of 
these  observations  were  distilled  from  Chapter  3's  discussion  about  commanders  not  really  being 
empowered  to  do  what  they  needed  to  do,  but  rather  used  their  time  to  "influence"  and  "shape" 
activities.  This  was  further  characterized  during  the  discussion  of  the  capabilities  and  limitations  of 
acquisition  portfolio  managers.  Chapter  4  is  more  explicit  in  this  regard.  Please  see  Table  5  and  the 
accompanying  discussion  on  this  topic. 

Observation  No.  9:  The  amount  of  documentation  required  by  the  overall  system  is  staggering 
and  can  be  the  driving  force  behind  program  delays.  For  instance,  the  process  by  which  documents  are 
drafted  and  approved  takes  an  inordinate  amount  of  time  doing  so.  The  existence  of  documentation 
that  documents  what  other  documents  have  required  is  an  example  of  a  process  wallowing  in 
bureaucracy.  This  observation  was  distilled  from  the  section  in  Chapter  4  entitled  "Other  issues." 
Discussions  in  this  section  about  the  "Timelines  of  the  System,"  "Coordination,"  "Accountability  and 
Power,"  and  "Process  Quality  and  Precision"  all  contributed  to  this  observation. 


207 


Observation  No.  10:  The  development  methodology  for  the  model  was  a  clever  way  to  translate 


some  of  the  problems  reported  during  the  interviews  and  represents  a  great  contribution  to 
understanding  the  acquisition  system.  Most  of  the  interviewees  were  not  able  to  give  an  exact  or 
definite  description  of  the  amount  of  time  or  effort  required  to  do  their  jobs.  However,  they  could  all 
give  a  range  of  time  as  well  as  a  percentage  associated  with  decision  points.  These  time  distributions 
and  probabilities  lend  itself  well  to  a  discrete  event  model,  versus  perhaps  a  system  dynamics  model. 
While  a  system  dynamics  model  has  many  perceived  advantages,  it  would  be  very  difficult  to  validate 
simply  from  the  standpoint  that  system  dynamics  is  not  easily  or  inherently  understood.  In  the  case  of 
this  model,  people  were  comfortable  talking  about  what  they  did  and  were  equally  comfortable  as  the 
model  was  being  validated  by  them.  The  simulation  and  the  results  are  only  based  upon  what  people 
have  shared.  Then,  these  same  people,  as  well  as  others  who  had  never  before  been  contacted,  were 
able  to  go  and  verify  the  model  construct.  This  observation  was  distilled  from  some  of  the  modeling 
challenges  identified  in  the  literature,  the  interviewees  in  Chapters  3  and  4,  as  well  as  those  personnel 
who  helped  with  the  validation  of  the  "free  style"  model  in  Chapter  6. 

Quantitative  Findings 

The  results  obtained  by  studying  the  unaltered  model  and  subsequent  interventions  are  very 
interesting.  They  provide  some  insights  into  the  system  that  otherwise  have  been  the  subjects  of 
informed  speculation.  Many  of  the  qualitative  conclusions  above  have  been  "tested"  or  investigated 
using  "interventions"  or  experimental  tests  run  through  the  model  to  see  the  results.  The  main 
conclusions  of  this  effort  follow. 

Finding  No.  1:  The  fact  that  an  overwhelming  number  of  projects  actually  circumvent  portions  of 
the  traditional  acquisition  system  is  absolutely  extraordinary,  especially  in  context  of  traditionally 
recognized  new  product  development  best  practices  and  their  associated  processes.  The  ramifications 
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of  this  finding  include  an  acquisition  system  with  more  to  do  than  it  has  the  resources  to  accomplish. 


This  finding  is  demonstrated  in  Figure  48. 

Finding  No.  2:  The  greatest  expected  improvement  possible  in  the  model  was  around  20% 
improvement  to  the  mean  program  during  and  that  only  after  combining  ALL  potential  interventions. 
This  improvement  statistic  likely  represents  the  lower  bound  of  any  possible  outcomes  of  any  chosen 
intervention  due  to  the  underlying  assumptions  present  in  the  model,  as  discussed  earlier.  If  a  20% 
improvement,  like  that  seen  in  Table  47,  is  not  judged  to  be  an  adequate  amount  of  improvement  to  the 
overall  system,  then  other  acquisition  alternatives  may  need  to  be  considered. 

Finding  No.  3:  The  most  improvement  that  a  single  intervention  can  make  on  the  system  is 
around  a  9%  decrease  to  the  average  duration  of  a  program  to  Milestone  C  per  Table  32.  This  particular 
intervention  speaks  to  the  authority  and  accountability  of  Acquisition  leaders.  Increasing  these 
authorities,  so  that  stopping  a  program  outright  at  particular  milestones  rather  than  allowing  them  to 
continue  becomes  more  commonplace,  is  a  realistic  interpretation  of  this  intervention.  The  actual 
implementation  of  such  an  intervention  would  require  changes  to  policy  and  approval  to  fold  funding  for 
such  efforts  back  into  existing  programs  rather  than  having  them  reallocated  for  another  new  program 
and  may  not  be  very  realistic  to  pursue  in  any  political  environment. 

Finding  No.  4:  The  most  effective  interventions  are  those  that  address  the  "quality"  of  system 
processes  by  attacking  sources  of  variability  in  the  system.  Improving  Systems  Engineering  processes 
and  reducing  technical  and  funding  uncertainties  cause  programs  to  execute  less  randomly.  These 
findings  were  demonstrated  by  the  model  and  reported  on  in  Tables  31,  34,  41,  42,  44,  and  46. 

Finding  No.  5:  The  sheer  complexity  of  the  system  complicates  the  testing  and  measurement  of 
proposed  interventions.  Real  world  interventions  are  complicated  in  that  years  must  transpire  before 
steady-state  results  relating  to  that  intervention  are  seen.  Unfortunately,  many  multiple  interventions 
are  injected  into  the  system  before  the  efficacy,  or  lack  thereof,  of  the  original  intervention  is  known. 
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Using  a  model  such  as  this  one  allows  for  differing  interventions  to  be  tested  in  isolation.  This 
represents  another  key  contribution  of  this  work. 

Finding  No.  6:  The  top  interventions,  across  any  measure,  are  all  combinations  of  differing 
interventions  as  seen  in  Tables  41  through  47.  Some  of  these  interventions  may  not  have  any  noticeable 
individual  effect,  but  together,  they  do  make  an  impact.  This  suggests  that  incremental  continuous 
improvement  has  not  exhausted  all  options  or  reached  any  limits,  although  the  evidence  may  suggest 
that  these  incremental  improvements  are  becoming  more  costly  as  the  "low  hanging  fruit"  has  already 
been  implemented. 

Finding  No.  7:  It  is  possible  to  take  purely  subjective  data  and,  when  organized  correctly, 
produce  quantitative  results  and  allow  for  experimentation.  This  finding  is  closely  aligned  with 
Observation  No.  10  as  it  provided  the  foundation  for  the  quantitative  exploration  of  this  subject. 

Overarching  Conclusions 

Conclusion  No.  1:  What  should  the  overall  acquisition  system  value?  Some  might  argue  the 
answer  to  this  question  is  cost,  schedule,  and  performance.  However,  these  do  not  appear  to  be  the 
things  that  are  really  valued  by  the  system.  During  the  course  of  this  study,  the  following  characteristics 
stand  out:  flexibility,  transparency,  and  quality.  If  flexibility  is  valued,  e.g.  being  able  to  start  programs 
at  will,  rush  things  through,  jump  ahead  of  other  programs  in  development  cycle,  then  the  system  must 
be  able  to  deal  with  the  funding  instability  that  ensues.  If  transparency  is  valued,  e.g.  process  checking, 
error-proofing,  consensus-building,  then  the  system  must  maintain  process  reviews  and  levels  of 
approval  and  accept  expensive  use  of  calendar  time.  If  quality  is  valued,  e.g.  not  giving  relief  for 
technical  requirements,  capabilities  and  performance  expectations,  then  expect  program  delays  and 
cost  increases  to  develop  and  mature  the  necessary  technologies,  or  deliver  the  expected  capabilities, 
etc.  Given  that  all  of  these  "outcomes"  are  present,  a  fair  conclusion  to  draw  is  that  the  system  places 
its  value  upon  flexibility,  transparency,  and  quality  or  performance  of  programs  that  go  through  the 
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process.  These  outcomes,  however,  are  diametrically  opposed  to  the  stated  values  of  minimizing  cost 


and  schedule  and  delivering  an  acceptable  amount  of  "performance." 

Restated,  there  are  five  key  characteristics  the  Acquisition  System  values:  cost,  schedule, 
performance,  transparency,  and  flexibility.  For  any  program,  pick  three  at  the  expense  of  two,  and 
remember  transparency,  flexibility,  and  performance  are  almost  always  non-negotiable. 

Conclusion  No.  2:  In  general,  the  people  working  within  the  process  are  hard  working  and 
dedicated  personnel,  and  their  interests  are  often  well  aligned  with  those  of  the  nation.  By  and  large, 
they  are  absolutely  committed  to  doing  the  right  thing  and  know  their  particular  jobs  well.  Similarly,  the 
idea  that  problems  in  the  acquisition  system  are  the  problem  of  acquisition  alone  is  not  correct.  These 
problems  are  the  result  of  emergent  behaviors  of  the  overall  Acquisition  system.  Indeed,  all  of  the 
evidence  gathered  and  presented  in  this  work  suggests  it  is  a  systems  problem. 

Conclusion  No.  3:  No  silver  bullet  exists  that  will  fix  the  acquisition  system.  Rather,  the 
extraordinary  complexity  of  the  current  system  makes  it  difficult  to  develop  and  test  interventions  that 
will  result  in  outcomes  aligned  with  the  original  intention.  Furthermore,  the  time  required  for  the  effect 
of  a  particular  intervention  to  be  manifest  is  usually  on  the  order  of  several  years,  far  outside  the 
longevity  of  most  policymaker's  tenure.  This  allows  the  system  to  be  frequently  criticized,  interventions 
made  to  demonstrate  the  ability  of  policymakers  and  politicians  to  "do  something"  about  acquisition, 
and  relieve  those  responsible  of  any  unintended  consequences  from  being  held  accountable  for  their 
actions.  Thus,  the  system  is  constantly  being  adjusted  chasing  the  never-ending  goal  of  acquisition 
reform.  A  corollary  to  this  might  be  that  the  silver  bullet  mindset  exists  with  some  in  leadership  circles. 
Flowever,  the  model  shows  that  multiple  interventions  will  be  far  more  effective  than  any  single 
intervention  or  "silver  bullet." 
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Policy  Implications  and  Potential  System  Improvements 

There  are  many  lessons  to  be  learned  from  the  results  of  this  study.  As  policy  is  developed  and 
recommended  for  implementation,  more  concerted  effort  needs  to  be  made  regarding  what  potential 
systemic  effects  any  policy  may  have  on  the  overall  system.  A  model  such  as  the  one  developed  here 
may  provide  insights  not  otherwise  seen  and  may  avert  costly  mistakes.  The  complexity  of  today's 
existing  system  demands  greater  fidelity  and  confidence  in  the  viability  and  efficacy  of  new  and/or 
changed  policies.  This  work  suggests  that  current  efforts  to  measure  the  effects  of  policy  interventions, 
process  changes  and  other  changes  are  falling  short  of  its  goal. 

Research  results  suggest  continuing  improvements  to  the  existing  system  still  works,  although 
the  evidence  also  suggests  that  the  impact  of  continuous  improvement  is  beginning  to  show  diminishing 
returns.  Is  it  time  to  suggest  dramatic  and  wholesale  changes  to  the  Acquisition  system?  Does  the 
entire  system  need  to  be  scrapped  and  rebuilt  from  scratch?  The  next  time  a  blue-ribbon  panel  is 
commissioned  to  study  or  recommend  improvements  to  the  Acquisition  system;  these  questions  should 
be  addressed  early  and  up  front. 

Until  that  time,  given  that  the  Acquisition  system  values  five  characteristics  instead  of  the  three 
valued  by  program  managers  and  taxpayers  alike,  efforts  should  be  made  to  define  and  measure  these 
other  two  characteristics.  For  instance,  one  way  to  add  value  to  the  notion  of  transparency,  is  to  have 
records  that  reflect  what  really  happens.  As  noted  in  Chapter  6  on  verification  and  validation,  one  of  the 
more  frustrating  portions  of  this  research  was  finding  enough  valid  data  to  use  in  this  research.  It  simply 
does  not  exist  and  often,  when  it  does,  there  is  enough  conflicting  information  to  destroy  all  confidence 
in  the  fidelity  of  the  data.  More  "honest  signals"  are  needed  that  cannot  be  faked,  fudged,  or 
manipulated  that  also  has  a  meaning  to  the  "other  side,"  whether  they  are  the  taxpayer,  the  war  fighter 
or  any  other  customer.  If  records  and  recordkeeping  were  improved,  there  would  be  a  better 
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understanding  of  the  true  costs  of  system  development,  as  well  as  an  improved  ability  to  assess  the 
efficacy  of  any  intervention  made  to  the  system. 

Other  improvements  to  the  system  that  affect  transparency  would  be  to  streamline  the 
approval  and  accountability  functions  within  the  DOD.  There  are  far  too  many  organizations  and 
approval  bodies  that  a  program  must  navigate  through  or  get  permission  from.  The  cost  of  doing 
business  this  way  is  very  time-consuming  and  distracts  from  the  development  of  the  program.  However, 
a  change  like  this  would  also  work  against  the  system's  desire  for  transparency,  e.g.  the  consensus 
building,  the  desire  for  openness.  A  carefully  defined  balance  would  need  to  be  struck  between  the 
competing  desires  of  transparency  and  keeping  to  a  shorter  schedule. 

Similarly,  most  ways  that  would  improve  flexibility,  such  as  finding  ways  to  start  new  programs 
or  remove  the  "colors  of  money"  that  constrain  the  ability  of  personnel  to  do  their  jobs,  comes  at  the 
expense  of  transparency.  Furthermore,  compelling  arguments  exist  to  restrict  flexibility  to  start  new 
programs  or  to  make  wholesale  changes  to  the  plans  of  current  systems  in  development,  e.g.  such  as 
the  potential  of  overloading  or  losing  control  of  the  capacity  of  the  system. 

The  author,  however,  recommends  that  the  principles  of  personal  integrity,  personal 
accountability,  and  development  speed  be  re-enthroned  as  values  into  systems  development.  The 
organizational  stovepipes  between  JCIDS,  PPBE,  and  acquisition  should  be  removed  and  an  organization 
built  from  a  systems  perspective  should  emerge.  Operations  such  as  combat  operations,  etc.,  should 
not  be  allowed  to  touch  money  allocated  for  system  development  and  services  ought  to  compete  for 
the  right  to  deliver  the  capabilities  the  war  fighter  wants.  If  the  portfolio  model  is  used,  and  the 
author's  opinion  is  that  product  portfolio  management  is  still  one  of  the  best  system  development 
practices  around,  leaders  of  those  portfolios  should  be  given  complete  authority  and  responsibility  for 
those  programs  within  their  portfolio.  "Colors  of  Money"  ought  to  be  eliminated  or  severely  curtailed  if 
it  prevents  a  portfolio  leader  from  getting  their  job  done.  Duplicative  staffing  functions  at  Headquarters 
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should  be  eliminated  and  personnel  be  pushed  out  to  the  various  development  centers.  Headquarters 


should  accept  the  responsibility  of  working  the  interrelationship  issues  between  programs.  Finally,  the 
integration  of  the  different  service's  acquisition  systems  ought  to  be  pursued.  Just  as  the  Goldwater- 
Nichols  act  made  the  services  "fight"  from  a  joint  perspective,  the  establishment  of  a  joint  acquisition 
system  would  fundamentally  change  the  way  the  system  "equips"  its  soldiers,  sailors,  and  airmen.  Clear 
priorities  could  be  established  and  promulgated  from  a  joint  war  fighter's  perspective,  something  that  is 
lacking  today.  Such  wholesale  changes  would  require  several  statutory  changes  to  allow  this  to  occur 
and  may  be  politically  too  sensitive  at  this  time  to  accomplish.  Nevertheless,  the  introduction  of  an 
integrated  acquisition  system,  with  true  authorities  and  responsibilities  for  the  development  of 
portfolios  of  capability  would  address  many  of  the  causal  factors  alluded  to  in  this  work  of  research  and 
be  a  historic  and  positive  step  forward  in  the  troubled  saga  of  DOD  systems  development. 

Future  work 

Generally  speaking,  all  of  these  conclusions  need  additional  work.  The  results  of  this  model 
simply  suggest  areas  where  closer  looks  could  be  made  based  upon  experience,  the  intuition  of  others, 
and  the  preliminary  analysis  of  some  of  the  interventions  that  were  tested.  The  results  presented  here 
will  guide  subsequent  work  by  helping  establish  a  hierarchy  of  importance  of  potential  areas  that  would 
be  well-suited  for  further  investigation. 

Future  Work  Area  No.  1:  Identify  and  develop  enterprise  risk  measures.  One  such  measure 
might  be  based  upon  comparing  an  existing  program's  attributes  to  the  model  and  "projecting"  or 
propagating  the  model  forward  to  establish  a  program's  possible  distribution  at  completion.  This  could 
easily  lead  to  measures  comparable  to  the  nominal  baseline  at  certain  confidence  levels. 

Future  Work  Area  No.  2:  Are  there  other  attributes  of  a  program  that  affect  its  behavior  while 
going  through  the  system?  For  instance,  the  model  could  be  adapted  to  key  off  of  Technology  Readiness 
Levels  or  the  "novelty"  vs.  cost  or  complexity  of  the  program. 
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Future  Work  Area  No.  3:  Are  there  other  reasons  why  programs  seek  to  circumvent  portions  of 


the  overall  system?  For  instance,  what  is  the  dollar  value  of  a  system  that  goes  around  the  traditional 
acquisition  process  versus  one  that  doesn't?  This  can  be  looked  at  in  terms  of  actual  expenditures  as 
well  as  projected  costs  from  the  beginning  of  a  program. 

Future  Work  Area  No.  4:  Add  cost  data  to  the  model,  both  in  terms  of  the  actual  program,  but 
also  the  "costs"  of  individual  process  steps  and  decision  points. 

Future  Work  Area  No.  5:  Add  a  more  explicit  modeling  of  the  PPBE  to  this  model.  Explore  if  such 
a  model  is  more  appropriate  in  demonstrating  systems  behaviors. 

Future  Work  Area  No.  6:  Explore  why  certain  interventions,  such  as  funding  stability,  technical 
uncertainty,  test  trades,  and  other  individual  SE  reviews  did  not  have  a  greater  impact  on  program 
outcomes  vs.  the  baseline  case.  Certain  results  were  not  expected  and  pursuing  research  in  this  area 
would  help  determine  why  this  was  the  case  and  if  it  is  a  correct  representation  of  reality. 

Future  Work  Area  No.  7:  Other  things  like  adding  more  fidelity  to  the  model  and  the  model 
construction  to  provide  a  better  understanding  of  interactions,  as  well  as  attempting  to  extend  this 
model  into  a  model  of  the  enterprise  where  multiple  systems  in  development  were  able  to  coexist  and 
how  their  interactions  would  drive  and  affect  one  another.  This  would  require  additional  definition  and 
coding  methods  to  reflect  the  interactive  interrelationships  and  influences  that  occur  between  multiple 
projects. 

Future  Work  Area  No.  8:  Add  or  address  the  sustainment  activities  that  occur  in  the  overall 
system.  As  the  research  noted,  a  significant  amount  of  activity  goes  directly  from  the  very  early  stages 
of  the  Acquisition  system  into  the  sustainment  portion  of  system,  currently  run  by  acquisition  personnel. 

Future  Work  Area  No.  9:  Add  or  address  non-programs  of  record  to  the  model's  analysis.  These 
are  programs  that  are  so  small  in  terms  of  dollar-size,  development  time,  and  quantity  that  they  are  not 
subject  to  the  same  amount  of  scrutiny  as  other  programs,  particularly  from  a  financial  perspective. 
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Nevertheless,  the  quantity  of  these  programs  easily  dwarfs  the  total  number  of  ACAT  programs  by 
orders  of  magnitude. 

Recommendations 

Improving  the  overall  acquisition  system  outcomes  will  require  a  concerted  effort  on  the  part  of 
lawmakers  and  policymakers  to  clearly  define  what  attributes  of  the  acquisition  system  are  valued  and 
build  a  system  around  that.  The  results  of  this  work  suggest  some  areas  for  additional  scrutiny.  For 
instance,  as  already  noted,  multiple  interventions  are  required  for  significant  cycle  time  improvements. 
Does  this  make  a  compelling  case  for  a  "clean  sheet"  process  redevelopment? 

Leaders  should  ensure  individual  process  steps  truly  add  value  or  have  a  compelling  purpose 
versus  the  cost  and  resources  required  by  all  of  these  individual  system  pieces.  Eliminating  unnecessary 
or  duplicative  processes  and  decisions  will  reduce  program  development  time  and  cost. 

Strengthen  acquisition  swim  lane  capability  to  say  "no"  or  terminate  programs;  delegate  and/or 
establish  true  portfolio  authorities  and  capabilities.  For  initial  quality  improvements,  focus  on  delivering 
funding  stability,  e.g.  fully  fund  programs,  and  minimize  financial  turbulence. 

Finally,  place  a  premium  on  technical  excellence  and  high  standards  for  personnel  from  the  very 
beginnings  of  the  system. 

Summary 

This  research  has  systematically  examined  the  acquisition  system  used  by  the  United 
States  Air  Force.  A  systems  approach  was  used  to  investigate  the  three  major  systems  in  acquisition 
which  comprise  the  overall  acquisition  system.  It  was  hypothesized  that  taking  such  an  approach  would 
shed  new  insights  into  the  overall  behavior  of  the  acquisition  system  and  land  additional  explanation  to 
the  negative  outcomes  experienced  by  the  vast  majority  of  acquisition  systems  today.  The  merit  of  this 
approach  has  been  validated. 
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Through  a  series  of  qualitative  studies,  and  the  subsequent  development  of  a 


quantitative  simulation  model,  some  emergent  behaviors  and  performance  of  the  acquisition  system  in 
use  today  are  better  understood.  The  success  of  the  system  in  developing  and  fielding  systems  for  the 
Armed  Forces  of  the  United  States  is  remarkable  and  speaks  to  the  dedication  and  hard  work  of 
countless  individuals,  sometimes  working  in  very  difficult  environments  due  to  the  emergent  and 
unanticipated  attributes  of  the  acquisition  system. 

The  tools  and  methodology  used  in  this  study  are  well  suited  for  adaptation  and  modification  to 
other  complex  socio-technological  systems  in  order  to  study,  better  understand  and  identify  emergent 
behaviors  and  system  outcomes. 
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Appendix  A  -  Other  Studies  and  Recommendations  to 
Improve  Acquisition  Outcomes 

This  appendix  contains  a  brief  analysis  and  overview  of  the  literature  identifying  factors 
contributing  to  schedule  and  cost  growth  from  an  Enterprise  perspective.  During  the  course  of  this 
effort,  a  total  of  forty-three  documents  were  identified  as  having  great  potential  to  identify  general 
themes  and  trends.  The  search  topics  used  to  find  these  documents  were  "Acquisition  Schedule," 
"Schedule  growth,"  and  "Cost  growth."  There  were  three  primary  sources  that  were  searched.  First, 
the  RAND  website  was  visited  and  reviewed.  Second,  the  IDA  website  yielded  several  candidates.  Third, 
the  GAO  website  was  visited  and  searched  for  relevant  documents.  Fourth,  the  Defense  Technical 
Information  Center  (DTIC)  Technical  Document  website  was  searched.  This  site  contains  most  of  the 
reports  from  the  three  previous  websites,  including  many  historical  (archived)  documents  no  longer 
available  at  the  three  other  websites,  any  contracted  technical  study  done  by  any  DOD  entity,  theses 
and  dissertations  from  all  military  professional  and  graduate  schools,  as  well  as  studies  and  theses 
written  by  military  personnel  attending  school  full-time  at  civilian  institutions. 

The  documents  represent  a  range  of  qualitative  studies  through  quantitative  predictive  studies. 
All  noted  issues  with  sample  size  and  data  reliability,  but  several  unifying  themes  are  evident.  Of  the 
forty-three  documents  identified,  only  thirty-one  source  documents  were  ultimately  reviewed.  Twelve 
other  documents  were  deemed  "not  relevant"  to  the  topic  at  hand.  A  subset  of  the  reviewed 
documents  was  actually  pertinent  to  the  intent  of  this  exercise  and  will  be  discussed  here. 

Key  Takeaways 

Among  the  key  takeaways  for  Enterprise  performance:  Since  the  1950s,  cost  growth  of  weapon 
systems  has  averaged  around  40%.  Annual  cost  growth  was  significantly  affected  by  the  Packard 
Reforms  around  1969.  This  reflects  systemic  behavior  of  the  overall  system. 


226 


Among  the  key  takeaways  for  schedule:  cost  and  schedule  are  coupled;  the  longer  the  program, 


the  more  likely  the  chance  a  schedule  slips;  shorter  programs  get  done  sooner.  "Decisions"  are  the 
source  of  most  schedule  slips. 

Takeaways  regarding  cost  issues  in  acquisition:  among  the  root  causes  are  "decisions"  that  are 
made.  Other  factors  may  include  political  party  influence  on  DOD  behavior,  e.g.  well  outside  the  realm 
of  control  for  programs.  Other  significant  factors  include  over-optimistic  estimates  of  program  cost, 
contractor  turbulence  at  lower  levels,  etc. 

Finally,  from  an  enterprise  perspective,  the  portfolio  of  programs  is  growing  at  a  rate  faster  than 
the  budget  and  will  soon  be  unsustainable. 

Additional  details  and  more  detailed  examples  follow  below,  but  the  key  takeaway  is  this:  there 
are  many,  many  things  that  contribute  to  schedule  and  cost  growth  and  some  of  the  most  relevant  are 
those  that  are  systemic  and  cross-process  within  the  Air  Force. 

Discussion  of  Individual  Studies 

A  RAND  study  published  in  2006,  titled,  "Measuring  the  Statutory  and  Regulatory  Constraints  on 

DOD  Acquisition:  Research  Design  for  an  Empirical  Study"  [129],  looked  at  the  problems  with  the  cost  of 

compliance  of  rules  and  regulations  on  the  acquisition  system.  They  could  not  find  any  "hard"  evidence, 

but  felt  that  these  rules  and  regulations  did  impose  "costs"  on  the  programs.  The  five  areas  deemed 

most  burdensome  were  the  "Clinger-Cohen  Act,  the  Core  law,  the  50-50  Rule,  program  status  reporting, 

program  planning  and  budgeting,  technical  data,  and  testing." 

Another  Rand  study,  titled  "An  Analysis  of  Weapon  System  Cost  Growth"  [130],  found  that  the 

acquisition  system  can't  explain  all  of  the  problems. 

"We  have  not  yet  fully  examined  an  important  set  of  potential  explanatory  variables  - 
institutional  and  incentive  structure  factors  -  that  may  be  fundamental  drivers  of  cost 
growth. ..The  inability  of  any  single  factor  to  explain  large  portions  of  observed  cost  has 
important  policy  implications.  It  suggests  that  any  policy  solution  of  necessity  will  be  complex, 
incorporating  all  aspects  of  the  acquisition  process  and  requiring  changes  in  behavior  in  all 
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responsible  parties,  from  the  system  program  office  through  Congress.  Further,  inflation  is 
notoriously  difficult  to  estimate  accurately,  and  quantity  changes  may  be  necessary  because  of 
changes  in  the  budget  environment  or  threat  -  factors  well  beyond  the  control  of  program 
management.  Additionally,  the  very  large  uncertainty  inherent  in  developing  advanced  system 
suggests  that  cost  risk  never  can  be  removed  completely."  (Pg  xiv) 

RAND,  in  a  study  titled,  "Measuring  the  Statutory  and  Regulatory  Constraints  on  Department  of 
Defense  Acquisition"  [131],  looked  at  the  time  devoted  to  different  issues  at  the  program  office  level  in 
this  study.  They  could  not  find  any  area  where  a  policy  change  would  save  significant  dollars  or  reduce 
program  cycle  times.  However,  one  outcome  of  this  study  was  the  recognition  that  the  PPBE  dominated 
most  of  the  programs'  expression  of  time,  which  was  then  followed  by  cost,  schedule,  and  performance 
reporting  data  (CSP)  (pg  20).  In  the  PPBE  area,  the  largest  identified  activity  was  recorded  on  de-scoping 
a  portion  of  the  program  to  pay  for  a  funding  shortfall  elsewhere,  followed  by  "funding  drills".  "What-if" 
exercises  required  the  second  highest  level  of  effort  in  the  PPBE  area.  However,  the  activity  of 
budgeting  was  the  largest  area  (accounting  for  68%  of  the  time  in  PPBE)  in  a  general  category  of  "other" 
(pgs  26-28). 

While  examining  CSP  functions,  RAND  noted  that  the  reporting  activity  required  the  second 
highest  level  of  effort.  Some  of  the  more  time  consuming  tasks  included  monthly  acquisition  reports, 
smart  charts,  etc.  (pg  29). 

Additionally,  there  were  periods  of  time  where  the  focus  of  the  program  staff  was  confined  to  a 
limited  set  of  activities,  cutting  across  statutory  areas,  related  to  a  specific  event,  statute  or  regulation, 
or  reporting  activity,  (pg  44) 

In  terms  of  actual  impacts  to  program  schedule  and  cost,  only  one  instance  was  documented, 
and  this  impact  came  from  outside  of  the  acquisition  system:  the  problem  of  getting  more  money  than 
was  requested.  It  caused  a  complete  restructuring  of  the  program.  It  took  nine  months  for  the  funding 
profile  change,  seven  months  for  the  color-of-money  change,  and  six  months  to  complete  the  additional 
testing  (pg  54). 


228 


A  study  of  Navy  contracts  over  a  twenty-year  period  found  little  variation  in  the  cost  growth 


outcomes  of  ACAT  I,  II,  or  III  programs  [132],  It  did  note  that  the  portfolio  age  of  programs  has  increased 
significantly.  It  noted  also  from  other  studies  that  programs  that  finish  "early"  or  "late"  tend  to  have 
more  cost  growth  than  those  that  finish  "on  time"  and  that  development  time  is  correlated  with  cost, 
where  a  $1  million  cost  increase  is  associated  with  a  1.7  month  increase  in  development  time. 

An  AFIT  thesis  on  the  Cost  and  Schedule  growth  for  Military  Space  Systems  [133]  found  that  cost 
growth  was  associated  with  type  and  program  size,  where  schedule  growth  was  associated  with 
program  "volatility,"  e.g.  the  number  of  changes  to  the  original  estimate,  technical  problems,  and  design 
changes.  Further,  it  reports  that  modification  programs  experience  lower  average  total  cost  and  lower 
cost  growth  (pg  32).  Further,  the  length  of  the  R&D  phase  or  the  length  of  the  Production  phase  are 
good  indicators  of  the  likelihood  and  amount  of  cost  growth  (pg  34).  The  thesis  also  reported  on 
another  study  where  cost  and  schedule  growth  are  higher  for  programs  that  are  initiated  during  times 
when  the  Democratic  party  has  a  strong  majority  in  Congress,  but  that  a  Democratic  president 
correlates  with  reduced  cost  overruns  for  that  year.  However,  another  study  found  that  the  same 
political  party  controlling  both  houses  of  congress  or  control  of  the  Senate  and  Presidency  correlates 
with  increase  cost  overruns  for  that  year  (pg  35).  Still  another  study  found  that  external  guidance  such 
as  oversight  reviews,  legislation,  and  other  directives  are  associated  with  higher  schedule  growth  (pg 
35). 

"Interestingly,  for  cost  growth,  the  qualitative  studies  and  the  quantitative  studies  differ  on  the 
factors  they  considered  and  thus  differ  on  which  factors  they  find  contribute  most  to  cost 
growth.  The  most  likely  cause  of  this  disconnect  is  that  quantitative  studies  often  limit  their 
predictor  variables  to  those  available  in  the  SAR,  and  many  of  the  factors  considered  in 
qualitative  studies  are  unlikely  to  be  available  for  the  large  number  of  programs  considered  by 
quantitative  studies."  Pg  45 

An  AFIT  thesis  titled  "Cost  growth  in  weapons  systems:  re-examining  rubber  baselines  and 
economic  factors,"  published  in  2007  [134],  found  that  "the  number  of  rebaselines  for  an  MDAP  does 
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predict  schedule  growth  and  two  or  more  rebaselines  predicts  cost  growth"  (pg  7).  The  thesis  also 

found  that  technical  maturity  and  contract  length  are  linked  because  the  DOD  "appeared  to  be 

preoccupied  with  new  technology  regardless  of  the  cost"  (pg  10). 

"Only  two  of  the  independent  variables  used  to  analyze  the  occurrence  of  cost  overruns  proved 
to  be  statistically  significant.  These  two  variables  were  the  number  of  rebaselines  and  the  length 
of  the  contract.  However,  both  variables  were  statistically  significant  to  the  one  percent  level, 
indicating  a  very  powerful  positive  influence  on  the  likelihood  of  an  overrun  occurring.  As  such, 
contract  budget  instability  and  extending  the  length  of  a  contract  both  add  to  the  likelihood  of  a 
contract  experiencing  a  cost  overrun.  Each  time  a  contract  is  rebaselined  it  is  two  percent  more 
likely  to  experience  a  cost  overrun  while  an  additional  year  in  program  length  adds  3.6  percent 
to  the  likelihood  of  a  cost  overrun."  (Pg  26) 

The  AFIT  thesis,  titled  "Analysis  of  Cost  and  Schedule  growth  on  sole  source  and  competitive  AF 
contracts,"  published  in  1993  [135],  found  that  sole  source  contracts  exhibited  an  average  of  57%  higher 
cost  growth  in  all  areas  and  that  schedule  growth  was  over  four  times  greater  than  the  schedule  growth 
of  competed  contracts. 

The  AFIT  thesis  titled  "Why  schedules  slip:  Actual  reasons  for  Schedule  Problems  Across  Large 
Air  Force  System  Development  Projects,"  published  in  1995  [136],  contained  some  interesting  results. 
The  thesis  is  based  on  a  sample  of  twenty-two  large  EMD  programs  from  1981  to  1994.  It  excludes  R&D 
programs  and  is  a  descriptive  study  only.  Furthermore,  it  only  reviews  efforts  managed  at  ESC.  The 
thesis  identified  549  reasons  for  schedule  difficulties.  The  source  of  this  data  came  from  contractor 
generated  Cost  Performance  Reports.  The  "Seven  Categories  (technical  problems,  late  subcontractors, 
manufacturing  problems,  design  changes,  late  data,  contracting,  and  staffing)  accounted  for  49  percent 
of  the  frequency,  57  percent  of  the  schedule  variance  (in  dollars),  and  49  percent  of  the  schedule 
variance  (in  work  days)"  (Pg  viii). 
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Figure  52:  Depiction  of  categories  why  schedules  slip  across  development  efforts 


Top  Five  Categories 
(Rank  Ordered) 

Frequency 

Total  Schedule  Variance 

($) 

Total  Schedule  Variance 
(Work  Days) 

Technical  Problems 
Subcontractor  Late 

Late  Data 

Manufacturing  Probs 
Staffing 

Technical  Problems 
Subcontractor  Late 

Design  Changes 
Manufacturing  Probs 
Contracting 

Subcontractor  Late 
Manufacturing  Probs 
Technical  Problems 
Contracting 

Design  Changes 

Bottom  Five  Categories 
(Rank  Ordered) 

Frequency 

Total  Schedule  Variance 
($) 

Total  Schedule  Variance 
(Work  Days) 

Miscellaneous  Delays 
Inventory  Mgt 
Req’ments  Changes 
Gov't  Stopped  Work 
Facility  Problems 

Late  Reviews 

Gov’t  Added  Work 
Req'ments  Changes 

Gov’t  Stopped  Work 
Facility  Problems 

Miscellaneous  Delays 
Inventory  Mgt 

Changed  Plans 

Req'ments  Changes 
Facility  Problems 

Table  50:  Most  and  Least  Significant  Categories  of  Reasons  for  Schedule  Problems 
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"The  seven  categories  listed  [above]  comprising  the  'top  five/  or  most  significant,  categories  of 
reasons  for  schedule  problems  account  for  49  percent  of  the  observed  reasons  (frequency),  57 
percent  of  the  schedule  variance  (in  dollars),  and  49  percent  of  the  schedule  variance  (in  work 
days).  Clearly,  these  categories  represent  reasons  more  deserving  of  management  attention 
than  the  eight  categories  listed  in  [the  table  above]  comprising  the  'bottom  five,'  or  least 
significant,  categories  of  reasons  for  schedule  problems,  which  account  for  only  7  percent  of  the 
observed  reasons  (frequency),  2  percent  of  the  schedule  variance  (in  dollars),  and  8  percent  of 
the  schedule  variance  (in  days)."  (Pg  73) 

An  AFIT  thesis,  published  in  2006,  titled  "How  does  the  political  nature  of  the  defense 
acquisition  process  affect  cost  growth?"  [137],  found  similar  results  as  reported  earlier  about  the 
Congress  and  Presidency.  It  also  found  "that  the  dispersion  of  defense  manufacturing  capacity  across 
the  county  inflates  cost  overruns  in  DOD  programs."  The  thesis'  literature  review  identified  another 
study  that  indicated  three  sources  of  cost  growth  are:  advanced  technology,  design  stability,  and 
schedule  risk  (Pg  26). 

A  Naval  Postgraduate  School  thesis,  "Cost  and  Schedule  Growth  during  weapon  system 

acquisition,  impact  of  selected  economic  and  political  factors,"  published  in  1990  [138],  found  some 

interesting  results  regarding  political  influence  on  the  system. 

"According  to  the  results,  Democratic  congressional  majorities,  not  Republican,  are  associated 
with  increased  cost  and  schedule  growth. ..This  result  cannot  be  easily  explained.  One  possible 
explanation  is  that  when  Democrats  hold  the  majority  in  Congress,  they  are  able  to  reduce 
appropriations  for  established  programs,  leading  to  program  stretch  out,  which  Tyson,  et  al., 
found  to  be  directly  related  to  cost  and  schedule  growth."  (Pg  53) 

"Nonetheless,  these  results  do  suggest  that  programs  initiated  under  both  Democratically 
dominated  Congresses  and  Democratic  Presidential  administrations  have  been  characterized  by 
greater  cost  and  schedule  growth. ..Weapon  system  cost  growth  appears  to  be  much  more 
strongly  related  to  the  influence  of  political  and  economic  factors  than  is  schedule  growth."  (Pg 
55) 

"This  suggests  that  schedule  growth  is  a  by-product  of  cost  growth"  (Pg  56). 

An  AFIT  Thesis,  titled  "Relating  initial  budget  to  program  growth"  and  published  in  2001  [139], 
used  Weibull  and  Rayleigh  distributions  to  model  cost  growth.  "This  model  explains  50.5%  of  the 
variation  in  schedule  growth  for  the  36  included  programs"  (Pg  3-35). 
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"Belcher  and  Dukovich  identified  12  factors  in  three  areas  contributing  to  development  program 
cost  growth  and  schedule  growth.  (See  Figure  2-7).  Our  cost  and  schedule  models  each  account 
for  only  a  single  of  Belcher  and  Dukovich's  factors,  funding  constraints.  Yet,  these  models 
explain  53.4%  of  the  variation  in  cost  growth  and  50.5%  of  the  variation  in  schedule  growth."  (Pg 
3-39) 

"...we  observe  from  the  validation  results  that  both  the  cost  model  and  schedule  model  tend  to 
underestimate  program  growth"  (Pg  4-1). 

An  IDA  Report,  titled  "Understanding  cost  and  Schedule  Growth  in  Acquisition  Programs,"  was 

published  in  1994  [140],  It  indicates  that  the  keys  to  preventing  schedule  growth  in  development  are 

technical  realism  and  willingness  to  make  tradeoffs.  The  report  examined  twenty  programs.  "The  major 

determinant  of  development  schedule  growth  was  increase  in  quantity  -  the  need  to  produce  more 

items  for  testing  than  planned"  (Pg  S-6).  "The  programs  with  high  total  program  cost  growth,  by 

contrast,  were  characterized  by  stretched  production  schedules"  (Pg  111-32). 

The  1994  Rand  report,  titled  "An  Analysis  of  Weapon  System  Cost  Growth"  [130]  indicated  that 

the  two  factors  with  greatest  effect  on  total  program  cost  growth  are  program  size  and  maturity.  "We 

have  not  yet  fully  examined  an  important  set  of  potential  explanatory  variables  -  institutional  and 

incentive  structure  factors  -  that  may  be  fundamental  drivers  of  cost  growth"  (Pg  xiv). 

"The  inability  of  any  single  factor  to  explain  large  portions  of  observed  cost  has  important  policy 
implications.  It  suggests  that  any  policy  solution  of  necessity  will  be  complex,  incorporating  all 
aspects  of  the  acquisition  process  and  requiring  changes  in  behavior  in  all  responsible  parties, 
from  the  system  program  office  through  Congress.  Further,  inflation  is  notoriously  difficult  to 
estimate  accurately,  and  quantity  changes  may  be  necessary  because  of  changes  in  the  budget 
environment  or  threat  -  factors  well  beyond  the  control  of  program  management.  Additionally, 
the  very  large  uncertainty  inherent  in  developing  advanced  system  suggests  that  cost  risk  never 
can  be  removed  completely."  (Pg  xiv) 

"In  times  of  increasing  budgets  cost  growth  also  increases,  while  decreasing  budgets  are 
associated  with  declining  cost  growth  ratios"  (Pg  46).  "...the  only  schedule  variable  significantly 
correlated  with  cost  growth  is  actual  program  duration..."  (Pg  46). 
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'A  Quantitative  Analysis  of  Factors  Affecting  Weapon  System  Cost  Growth,"  a  NPS  Thesis 


published  in  1987  [141],  looked  at  nine  weapon  systems  from  the  Army  and  Navy  using  Selected 
Acquisition  Reporting  (SAR)  data. 

"Each  cost  variance  was  classified  as  to  whether  it  was  attributable  to  a  mistake  in  the  cost 
estimating  process  or  a  post-Milestone  II  decision. ..Cost  growth  due  to  decisions  outweigh 
mistakes  by  a  factor  of  2.3  to  1.  A  majority  of  the  mistake  cost  growth  is  due  to  errors  in  the 
estimation  of  production  costs.  A  majority  of  the  decision  cost  growth  is  due  to  schedule 
slippage.  Low  cost  systems  have  2.4  times  as  much  mistake  cost  growth  as  high  cost  systems." 

(Pgii) 

"Mistakes  made  in  the  estimation  of  system  costs  make  up  30.6%  of  the  total  cost  growth  of  a 
system  while  decisions  make  up  69.4%  of  the  total  cost  growth... A  majority  of  the  decision  cost 
growth  is  attributable  to  schedule  slippage.  Some  of  this  schedule  slippage  can  be  attributed  to 
decisions  to  change  the  design  and  performance  requirements  of  the  system,  while  the 
remaining  amount  is  unexplained."  (Pg  xi) 

"A  majority  of  the  decision  cost  growth  occurs  in  the  Dsmmi  category.  The  Dsmmi  category  is 
used  to  classify  cost  variances  attributable  to  a  decision  to  change  the  procurement  schedule, 
shifts  in  the  multi-year  procurement  rates  or  in  different  management  initiatives.  A  detailed 
analysis  of  the  data  indicates  that  a  majority  of  the  Dsmmi  cost  growth  is  due  to  schedule 
slippage.  Some  of  this  schedule  slippage  can  be  attributed  to  decisions  to  change  the  design 
and  performance  requirements  of  the  system."  (Pg  40) 


The  1991  AFIT  thesis,  "Estimating  potential  cost  growth  of  the  most  probable  cost  estimate," 
[142]  determined  that  three  factors  were  "major  contributors  to  cost  growth  for  ASD  programs; 
technical  risk,  configuration  stability,  and  schedule  risk"  (Pg  vii).  Sixteen  programs  were  examined 
covering  a  time  span  from  1980  to  1988. 

An  interesting  ICAF  Thesis,  published  in  1993  and  titled  "Cost  Growth  in  DOD  Major  Progams:  A 
Historical  Perspective,"  [143]  suggested  five  factors  existed  for  cost  growth:  requirements  definition, 
cost  estimating,  program  management,  contracting,  and  budgetary  issues.  Additionally,  the  literature 
review  suggested  these  "...factors  significantly  affect  cost  growth  in  major  systems.  Their  results 
identified  three  factors  at  the  95%  confidence  level:  growth  in  the  development  schedule;  decisions  to 
"stretch  out"  programs;  and  the  length  of  the  development  schedule"  (Pg  21).  However,  Bliss  authored 
a  study  which  directly  contradicted  the  results  from  the  IDA  study  referenced  above  stating  that 
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program  size  and  type  of  system  were  the  most  significant,  while  technical  challenge,  slips  in  EMD,  and 


program  stretch  were  NOT  significant  (Pg  22). 

The  GAO  report,  titled,  "Defense  Acquisitions:  Better  Weapon  Program  outcomes  require 
discipline,  accountability,  and  fundamental  changes  in  the  acquisition  environment"  [144],  found  the 
following: 

"DOD's  portfolio  of  weapon  system  programs  has  grown  at  a  pace  that  far  exceeds  available 
resources.  From  1992  to  2007,  the  estimated  acquisition  costs  remaining  for  major  weapons 
programs  increased  almost  120  percent,  while  the  annual  funding  provided  for  these  programs 
only  increased  57  percent.  Current  programs  are  experiencing,  on  average,  a  21-month  delay  in 
delivering  initial  capabilities  to  the  warfighter— often  forcing  DOD  to  spend  additional  funds  on 
maintaining  legacy  systems."  (Abstract) 

"Several  underlying  systemic  problems  at  the  strategic  level  and  at  the  program  level  continue 
to  contribute  to  poor  weapon  system  program  outcomes.  At  the  strategic  level,  DOD  does  not 
prioritize  weapon  system  investments  and  the  department's  processes  for  matching  warfighter 
needs  with  resources  are  fragmented  and  broken.  Furthermore,  the  requirements  and 
acquisition  processes  are  not  agile  enough  to  support  programs  that  can  meet  current 
operational  requirements.  At  the  program  level,  programs  are  started  without  knowing  what 
resources  will  truly  be  needed  and  are  managed  with  lower  levels  of  product  knowledge  at 
critical  junctures  than  expected  under  best  practices  standards.  In  the  absence  of  such 
knowledge,  managers  rely  heavily  on  assumptions  about  system  requirements,  technology,  and 
design  maturity,  which  are  consistently  too  optimistic.  This  exposes  programs  to  significant  and 
unnecessary  technology,  design,  and  production  risks,  and  ultimately  damaging  cost  growth  and 
schedule  delays.  DOD  officials  are  rarely  held  accountable  for  these  poor  outcomes  and  the 
acquisition  environment  does  not  provide  the  appropriate  incentives  for  contractors  to  stay 
within  cost  and  schedule  targets,  making  them  a  strong  enabler  of  the  status  quo."  (Pg  2) 

Figure  1  in  this  report  is  recommended  as  it  builds  a  strong  case  about  forthcoming  problems.  It 

shows  the  re-emergence  of  the  "Bow  Wave,"  a  huge  amount  of  funding  requirements  lying  just 

"outside"  of  the  official  budgeting  cycle  (Pg  4).  Furthermore,  "Poor  program  execution  contributes  to 

and  flows  from  shortfalls  in  DOD's  requirements  and  resource  allocation  processes"  (Pg  6). 

"Over  the  past  several  years  our  work  has  highlighted  a  number  of  underlying  systemic  causes 
for  cost  growth  and  schedule  delays  both  at  the  strategic  and  at  the  program  level.  At  the 
strategic  level,  DOD's  processes  for  identifying  warfighter  needs,  allocating  resources,  and 
developing  and  procuring  weapon  systems— which  together  define  DOD's  overall  weapon 
system  investment  strategy— are  fragmented  and  broken.  At  the  program  level,  the  military 
services  propose  and  DOD  approves  programs  without  adequate  knowledge  about 
requirements  and  the  resources  needed  to  successfully  execute  the  program  within  cost, 
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schedule,  and  performance  targets.  In  addition,  DOD  officials  are  rarely  held  accountable  for 
poor  decisions  or  poor  program  outcomes."  (Pg  6) 

"Ultimately,  the  process  produces  more  demand  for  new  programs  than  available  resources  can 
support.  This  imbalance  promotes  an  unhealthy  competition  for  funds  that  encourages 
programs  to  pursue  overly  ambitious  capabilities,  develop  unrealistically  low  cost  estimates  and 
optimistic  schedules,  and  to  suppress  bad  news.  Similarly,  DOD's  funding  process  does  not 
produce  an  accurate  picture  of  the  department's  future  resource  needs  for  individual 
programs— in  large  part  because  it  allows  programs  to  go  forward  with  unreliable  cost  estimates 
and  lengthy  development  cycles— not  a  sound  basis  for  allocating  resources  and  ensuring 
program  stability.  Invariably,  DOD  and  the  Congress  end  up  continually  shifting  funds  to  and 
from  programs— undermining  well-performing  programs  to  pay  for  poorly  performing  ones." 

(Pg  6) 

"Constraining  development  cycles  would  make  it  easier  to  more  accurately  estimate  costs,  and 
as  a  result,  predict  the  future  funding  needs  and  effectively  allocate  resources.  We  have 
consistently  emphasized  the  need  for  DOD's  weapon  programs  to  establish  shorter 
development  cycles.  DOD's  conventional  acquisition  process  often  requires  as  many  as  10  or  15 
years  to  get  from  program  start  to  production.  Such  lengthy  cycle  times  promote  program 
funding  instability— especially  when  considering  DOD's  tendency  to  change  requirements  and 
funding  as  well  as  frequent  changes  in  leadership.  Constraining  cycle  times  to  5  or  6  years  would 
force  programs  to  conduct  more  detailed  systems  engineering  analyses,  lend  itself  to  fully 
funding  programs  to  completion,  and  thereby  increase  the  likelihood  that  their  requirements 
can  be  met  within  established  time  frames  and  available  resources."  (Pg  9) 

There  is  also  a  very  nice  appendix  documenting  many  of  the  recent  changes  in  law  aimed  at 

acquisition  (Pg  14). 

Impossible  Certainty:  Cost  Analysis  in  Weapon  System  Acquisition,  is  a  RAND  report  published  in 

2006  [40]  reviewing  how  cost  analysis  is  done  in  acquisition  programs  of  the  DOD. 

"RAND  conducted  research  that  explored  and  reviewed  various  risk  assessment  methodologies 
that  could  be  applied  to  cost  estimating  for  major  acquisition  programs.  RAND  explored  how 
these  risk  methods  and  policies  relate  to  a  total  portfolio  of  programs.  The  research  also 
explored  how  risk  information  can  be  communicated  clearly  to  senior  decisionmakers."  (Pg  xx) 

RAND  documents  some  of  the  challenges  faced  during  the  cost  analysis  phase.  "All  of  this  leads 

to  a  reluctance  on  the  part  of  acquisition  program  managers  and  analysts  to  pursue  any  kind  of  risk 

analysis  for  their  cost  estimates;  in  the  absence  of  guidance,  almost  any  choice  can  be  criticized  on 

technical  grounds  by  someone  who  does  not  like  the  answer"  (Pg  14). 

"Proponents  of  qualitative  assessment  assert  that  trying  for  more-precise  quantification  of 
probability  and  cost  increase  is  meaningless  in  the  face  of  substantial  uncertainty.  However,  the 
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qualitative  methods  are  not  as  useful  in  aggregating  lower-level  risks  to  projectwide  risk 
assessments,  because  it  is  not  clear  how  to  combine  such  broad  ranges  of  probability  and  cost 
increase  into  a  final,  single  qualitative  risk  assessment.  In  particular,  since  one  major  output  of  a 
cost  risk  analysis  is  to  set  the  budget  for  a  project,  quantitative  methods  are  more  appropriate. 
Qualitative  methods,  however,  can  be  valuable  for  providing  a  better  understanding  of 
individual  risks  and  for  developing  a  risk  mitigation  plan."  (Pg  43) 

RAND  does  a  nice  job  reviewing  five  different  probabilistic  methods  used  in  cost  estimating. 

"Here  we  review  five  probabilistic  methods:  propagation  of  errors,  expert  judgment,  error  of  estimating 

method,  method  of  moments,  and  Monte  Carlo  simulation"  (Pg  51). 

"The  most  often  mentioned  sources  of  program  risk  by  decisionmakers  were  the  following: 
Overall  cost  of  a  program  getting  set  before  any  real  analysis  of  the  program  risks  is  performed. 
A  related  issue:  The  constraint  on  program  estimates  and  funding  driven  by  affordability  within 
the  Planning,  Programming,  and  Budgeting  System  (PPBS)  process.  Use  of  OSD-directed  inflation 
rates  that  do  not  reflect  program  contract  inflation  rates,  thereby  divorcing  known  funding 
requirements  from  availability  of  funding.  Use  of  point  estimates  without  including  what  the 
range  of  likely  costs  could  be.  Disconnects  between  requirements/capabilities  generation  and 
program  management  resulting  in  the  acquisition  community  promising  more  capability  than  a 
program  can  afford.  Failure  to  investigate  critical  assumptions  made  about  a  program  before 
key  decisions.  Underestimation  of  program  complexity  and  schedules,  especially  when  program 
advocates  assert  programs  under  review  "won't  be  like  previous  programs."  Failure  to  ensure 
that  the  test  community  was  "on  board"  early  enough  to  determine  that  requirements  or 
capabilities  were  "testable"  at  the  end  of  the  development  process.  Faulty  program  cost 
estimates  at  key  decision  milestones."  (Pg  74) 

"In  summary,  the  senior  acquisition  officials  generally  felt  that  •  Cost  growth  was  due  to  a  large 
number  of  causes,  some  of  which  were  beyond  the  control  of  the  acquisition  community,  so 
realistic  risk  assessments  would  not  eliminate  all  cost  growth  in  weapon  systems  •  The  current 
system  meets  their  needs  to  assess  risk  (since  they  are  in  a  position  to  ask  for  that  kind  of 
analysis)  •  Prescribing  formats  for  risk  presentations  might  constrain  true  risk  discussions  and 
that  risk  assessments  based  on  historical  analogous  program  performance  was  desired  (where 
data  allowed)  •  More  flexibility  in  openly  addressing  risk  funding  within  the  PPBS  and 
congressional  legislative  processes  would  allow  them  to  better  address  risk  and  decrease 
program  cost  growth  •  Risk  assessments  should  be  done  on  a  case-by-case  basis,  with  only 
guidelines  (as  opposed  to  regulations  or  directives)  as  to  content  of  the  risk  assessments  and 
perhaps  to  a  more  standardized  risk  nomenclature."  (Pg  79) 

RAND  suggest  there  are  some  risks  that  are  common  to  programs.  These  are:  Estimating 
Uncertainty,  Economic  Business  Base,  Technology,  Schedule,  and  Other  sources  of  cost  risk  (Pg  96). 

The  report  also  attempts  to  see  if  there  is  value  in  using  portfolio  techniques  in  managing 
programs.  In  the  section  titled,  "Risk  Management  for  a  Collection  of  Programs,"  (pg  135),  RAND 
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assembles  a  set  of  hypothetical  programs  into  a  portfolio  and  estimate  that  approximately  9%  of  cost 


could  be  saved  using  these  methods.  However,  "These  results  depend  on  the  following  assumptions: 
The  program  cost  probability  distributions  are  uncorrelated.  The  estimate  confidence  levels  are 
accurately  assessed.  The  contractors  and  program  managers  have  incentives  not  to  spend  the  reserves. 
The  risk  reserves  are  available  to  the  program  when  needed"  (Pg  138).  They  concluded  that  "although 
there  are  advantages  to  managing  program  cost  risk  at  the  "portfolio"  level,  there  are  substantial 
obstacles  to  doing  so  within  the  current  Planning,  Programming,  and  Budgeting  System  framework"  (Pg 
145). 


"Is  weapon  system  cost  growth  increasing?  A  Quantitative  Assessment  of  Completed  and 
Ongoing  programs"  is  the  title  of  RAND  report  MG-588  [145],  "Perhaps  the  most  important  finding  of 
the  analysis  is  that  development  cost  growth  in  the  past  three  decades  has  remained  high,  with  no 
significant  improvement"  (Pg  xx). 

"Over  the  years,  several  studies,  by  RAND  and  others,  have  attempted  to  identify  the  causes  of 
cost  growth  and  what  steps  can  be  taken  to  address  them.  These  causes  fall  into  the  following 
broad  areas:  overoptimism,  estimating  errors,  unrecognized  technical  issues,  requirements 
creep,  lack  of  incentives  to  control  cost,  and  schedule  extensions.  Therefore,  addressing  the 
issue  of  cost  growth  requires  vigorous  involvement  of  all  stakeholders  in  DOD."  (Pg  xxi) 

"Sources  of  Weapon  System  Cost  Growth:  Analysis  of  35  Major  Defense  Acquisition  Programs," 

is  the  name  of  another  RAND  report,  number  MG-670,  published  in  2008  [146],  It  attempts  to  address 

the  larger  issue  of  why  cost  growth  occurs.  The  report  scraps  the  seven  variance  categories  in  the  SAR 

for  four  major  categories:  "(1)  errors  in  estimate  and  planning,  (2)  decisions  by  the  government,  (3) 

financial  matters,  and  (4)  miscellaneous  sources"  (Pg  xiv)  with  a  table  of  sub-categories. 

"Total  (development  plus  procurement)  cost  growth  is  dominated  by  decisions,  which  account 
for  more  than  two-thirds  of  the  growth.  Most  decision-related  cost  growth  involves  quantity 
changes  (22  percent),  requirements  growth  (13  percent),  and  schedule  changes  (9  percent).  Cost 
estimation  (10  percent)  is  the  only  large  contributor  in  the  errors  category.  Growth  due  to 
financial  and  miscellaneous  causes  is  less  than  4  percent  of  the  overall  growth."  (Pg  xvi) 

"Decisions  accounted  for  the  majority  of  cost  growth  in  aircraft  and  helicopters  and  missiles, 
and  for  virtually  all  of  the  cost  growth  in  electronics.  Cost  estimating  was  the  single  largest  cost 
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growth  contributor  in  aircraft  and  helicopters  and  missile  programs  at  27  percent  and  15 
percent,  respectively.  Quantity,  at  18  percent,  was  the  single  largest  contributor  to  cost  growth 
in  electronics  programs."  (Pg  xviii) 

"Our  results  show  that  decisions  involving  changes  in  requirements,  quantities,  and  production 
schedules  dominate  cost  growth.  Therefore,  program  managers,  service  leadership,  and  Congress 
should  look  for  ways  to  reduce  changes  in  these  areas"  (Pg  xix). 

In  the  RAND  report  TR-343,  "Historical  Cost  Growth  of  Completed  Weapon  System  Programs," 
published  in  2006  [147],  it  reports  on  the  results  of  three  other  studies  that  suggest  schedule  growth  is 
correlated  with  cost  growth  (Pg  15). 

Summary  and  Conclusions 

In  conclusion,  the  literature  is  full  of  reports  and  studies  that  have  attempted  to  quantify  both 
quantitatively  and  qualitatively  reasons  why  weapon  system  cost  and  schedule  growth  occur. 
Unwittingly,  the  distilled  essence  of  these  materials  lends  support  to  the  approach  and  conclusions  of 
this  dissertation  research.  The  problems  are  systemic  in  nature  and  there  are  no  easy  fixes  or  answers. 


239 


Appendix  B  -  Sample  Questions  used  in  Acquisition  Study 

Questions  for  Portfolio  Managers 

Emphasize  that  this  is  about  their  job  as  a  portfolio  manager  (describe  a  "portfolio"  if  needed).  There  is 
no  right  or  wrong  answer.  This  interview  is  exploratory  in  nature  and  is  designed  to  learn  more  about 
portfolios,  the  job  of  being  a  portfolio  manager,  and  associated  items. 

Note: 

Questions  1-11  are  survey  type  questions  that  can  be  gathered  at  a  later  time 
Questions  17-19  are  key  questions  that  should  be  asked  in  all  interviews 

About  the  Portfolio  Manager 

1.  What  is  the  name  of  your  portfolio? 

2.  How  long  have  you  been  in  this  position? 

3.  What  kind  of  training  is  required  for  this  position? 

4.  What  is  your  professional  background? 

5.  What  are  your  duties  as  a  portfolio  manager? 

6.  What  other  duties  do  you  have  in  addition  to  those  of  a  portfolio  manager? 

About  the  portfolio 

7.  How  many  programs  make  up  your  portfolio? 

8.  How  many  people  directly  report  to  you? 

9.  How  many  people  are  you  responsible  for? 

10.  What  is  the  overall  dollar  size  of  your  programs? 

11.  What  are  the  ACAT  levels  of  your  programs? 

Portfolio  Strategy 

12.  Does  your  portfolio  have  an  overarching  strategy  or  vision? 

a.  What  is  it? 

b.  How  do  you  measure  progress  towards  reaching  the  portfolio  vision  or  strategy? 

i.  What  are  the  criteria  used? 

13.  What  is  the  strategic  vision  of  the  portfolio  that  you  are  a  part  of? 

a.  What  degree  of  importance  does  your  portfolio  have  compared  to  the  larger  overall 
portfolio? 

i.  What  are  the  criteria  used? 


Portfolio  Output 

14.  How  do  you  measure  portfolio  success? 

a.  What  measures  do  you  currently  use? 

i.  "Output"  or  "capability"? 

1.  How  much  did  your  portfolio  deliver  this  year?  Last  year? 

ii.  Stoplight  charts? 

1.  What  do  these  really  tell  you  about  your  portfolio? 

Portfolio  Manager  Capabilities 

15.  What  degree  of  control  do  you  have  over: 

a.  the  contents  of  your  portfolio? 
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i.  Inputs 

ii.  Outputs 

b.  the  resources  for  your  portfolio  programs? 

c.  the  requirements  placed  upon  your  portfolio  programs? 

16.  What  levers  of  control  over  the  portfolio  do  you  have? 

i.  People? 

ii.  Money? 

iii.  Schedules? 

iv.  Selection  authority  (start,  kill,  delay)? 

v.  Requirements? 

vi.  Other? 

b.  What  levers  of  control  do  you  wish  you  had? 

c.  Are  there  some  levers  of  control  that  others  have  and  you  do  not?  How  come? 

i.  Who  else  can  manipulate  the  "levers  of  control"  of  your  portfolio? 

Portfolio  Information/Decision  Making 

17.  What  kinds  of  information  do  you  use  to  make  portfolio  decisions? 

a.  What  information  is  most  effective  or  helpful? 

18.  What  kinds  of  information  do  you  wish  you  had  to  make  portfolio  decisions? 

19.  How  do  you  synthesize  information  from  multiple  programs  into  a  portfolio-level  view? 

20.  What  kinds  of  things  most  often  surprise  you  at  the  portfolio  level? 

a.  What  role  does  risk  play  in  your  portfolio  decision-making? 

b.  What  degree  of  risk  do  you  currently  carry  within  your  portfolio?  (risk  exposure) 

21.  How  do  you  use  measures  of  risk  to  manage  a  portfolio? 

a.  How  do  you  synthesize  portfolio-level  risk? 

22.  How  is  information  handled  by  the  portfolio? 

a.  How  do  you  communicate  news  about  your  portfolio  to  superiors?  (Upstream?) 

b.  Downstream? 

c.  How  often  are  you  "briefing"  various  staff  and  line  offices  about  your  portfolio 
programs? 

i.  What  is  the  ratio  of  decision  briefs  to  informational  briefs: 

1.  you  receive? 

2.  you  give  to  superiors? 

Internal  vs.  External  issuses 

23.  Describe  some  of  the  external  influences  or  "overhead"  that  impact  your  portfolio?  Explain  how 
the  portfolio  is  impacted?  Where  is  the  source  of  these  influences,  etc.? 

a.  Higher  Headquarters? 

b.  Air  Staff? 

c.  OSD? 

d.  Other  agencies? 

e.  Congress? 

f.  Individual  player  personalities? 

24.  How  do  you  deal  with  other  programs  not  belonging  to  your  portfolio  (if  applicable)? 

25.  What  programs  have  interdependencies  with  each  other  and  what  is  the  strength  of  that 
relationship? 

a.  Within  your  portfolio? 

b.  Outside  of  your  portfolio? 
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Appendix  C  -  Sample  questions  used  for  second  study 

Questions  for  Enterprise  participants 

Emphasize  that  this  is  about  portfolios  (describe  a  "portfolio"  if  needed).  There  is  no  right  or  wrong 
answer.  This  interview  is  exploratory  in  nature  and  is  designed  to  learn  more  about  the  enterprise, 
portfolios,  and  associated  items. 

About  the  Interviewee 

1.  What  is  the  name  of  your  job? 

2.  How  long  have  you  been  in  this  position? 

3.  What  kind  of  training  is  required  for  this  position? 

4.  What  is  your  professional  background? 

5.  What  are  your  duties? 

6.  What  other  duties  do  you  have  in  addition  to  those  of  your  job? 

About  the  organization 

7.  How  is  a  portfolio  defined? 

8.  How  many  programs  make  up  your  portfolio? 

9.  How  many  people  are  in  the  organization? 

10.  What  is  the  overall  dollar  size  of  your  programs? 

11.  How  are  your  programs  managed? 

Portfolio  Management 

12.  What  is  the  essence  of  materiel  development/the  portfolio  management  process? 

13.  Explain  your  understanding  of  the  system  used  to  manage  portfolios. 

14.  What  understanding  do  you  have  about  the  capacity  of  the  system  for  development  projects? 

15.  How  do  you  synthesize  information  from  multiple  programs  into  a  portfolio-level  view? 

16.  How  do  you  use  risk  to  manage  a  portfolio? 

17.  How  do  you  synthesize  portfolio-level  risk? 

Portfolio  Output 

18.  How  do  you  measure  portfolio  success? 

a.  What  measures  do  you  currently  use?  (Stoplight  charts?  What  do  they  tell  you?) 

i.  "Output"  or  "capability"? 

1.  How  much  did  your  portfolio  deliver  this  year?  Last  year? 

Portfolio  Manager  Capabilities 

19.  What  degree  of  control  do  you  have  over: 

a.  the  contents  of  your  portfolio? 

ii.  Inputs 

iii.  Outputs 

b.  the  resources  for  your  portfolio  programs? 

c.  the  requirements  placed  upon  your  portfolio  programs? 

20.  What  levers  of  control  over  the  portfolio  do  you  have? 

i.  People? 

ii.  Money? 
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iii.  Schedules? 

iv.  Selection  authority  (start,  kill,  delay)? 

v.  Requirements? 

vi.  Other? 

a.  What  levers  of  control  do  you  wish  you  had? 

b.  Are  there  some  levers  of  control  that  others  have  and  you  do  not?  How  come? 

i.  Who  else  can  manipulate  the  "levers  of  control"  of  your  portfolio? 

Portfolio  Information/Decision  Making 

21.  What  kinds  of  information  do  you  use  to  make  portfolio  decisions? 

a.  What  information  is  most  effective  or  helpful? 

b.  What  kinds  of  information  do  you  wish  you  had  to  make  portfolio  decisions? 

22.  What  kinds  of  things  most  often  surprise  you  at  the  portfolio  level? 

a.  What  role  does  risk  play  in  your  portfolio  decision-making? 

b.  What  degree  of  risk  do  you  currently  carry  within  your  portfolio?  (risk  exposure) 

Internal  vs.  External  issues 

23.  Describe  some  of  the  external  influences  or  "overhead"  that  impact  your  portfolio?  Explain  how 
the  portfolio  is  impacted?  Where  is  the  source  of  these  influences,  etc.? 

a.  Higher  Headquarters? 

b.  Air  Staff? 

c.  OSD? 

d.  Other  agencies? 

e.  Congress? 

f.  Individual  player  personalities? 

24.  How  do  you  deal  with  other  programs  not  belonging  to  your  portfolio  (if  applicable)? 

25.  What  programs  have  interdependencies  with  each  other  and  what  is  the  strength  of  that 
relationship? 

a.  Within  your  portfolio? 

b.  Outside  of  your  portfolio? 

Portfolio  Strategy 

26.  Does  your  portfolio  have  an  overarching  strategy  or  vision? 

a.  What  is  it? 

27.  How  do  you  measure  progress  towards  reaching  the  portfolio  vision  or  strategy? 

28.  What  is  the  strategic  vision  of  the  portfolio  that  you  are  a  part  of? 

29.  What  degree  of  importance  does  your  portfolio  have  compared  to  the  larger  overall  portfolio? 
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Appendix  D  -  Description  of  Model  and  Data  Documentation 

Introductory  description  and  explanation 

The  model  used  in  this  analysis  attempts  to  keep  the  representations  and  generalizations  simple 
but  have  enough  detail  to  make  the  model  worthwhile.  There  is  no  claim  of  100%  accuracy  or  complete 
representation  of  reality.  The  primary  purpose  of  the  model  is  to  serve  as  a  way  to  generate  questions 
and  understand  the  overall  system  in  a  way  that  has  not  been  done  before.  Like  every  model,  flaws 
exist  and  contain  generalizations  and  abstractions  that  can  be  debated.  From  the  highest  level,  the 
model  is  aptly  described  as  a  kind  of  nested  hierarchy  of  various  levels  with  each  level  becoming  more 
and  more  detailed.  A  less  detailed  discussion  about  the  model  is  in  Chapter  5. 

The  model  is  organized  around  swim  lanes.  Each  swim  lane  consists  of  a  functional  process,  as 
well  as  organizational  arrangement  in  the  United  States  Air  Force.  The  horizontal  axis  serves  as  a  loose 
representation  of  time  -  or  providing  a  temporal  anchor  to  the  description.  The  first  swim  lane  is 
considered  to  be  the  User  swim  lane.  This  swim  lane  is  the  source  of  many  different  ideas,  concepts,  as 
well  as  formal  direction  given  to  various  system  development  questions. 

The  second  swim  lane  is  titled  the  Requirements  swim  lane.  This  swim  lane  outlines  the  process 
of  generating  comments,  approval  and  staffing  of  a  requirements  document  necessary  for  the 
development  of  a  weapon  system. 

The  third  swim  lane  is  for  the  programming,  planning,  budgeting  and  execution  system  (PPBE)  of 
the  U.S.  Air  Force.  This  is  the  swim  lane  that  controls  the  administration  of  the  money  planning, 
disbursement  and  execution  processes.  Those  in  the  requirements  swim  lane  are  generally  responsible 
for  controlling  the  money  and  the  fourth  swim  lane,  titled  Acquisition,  is  responsible  for  spending  it. 

More  specifically,  the  fourth  swim  lane,  Acquisition,  is  where  all  of  the  project  or  program 
administration  and  activities  occur  for  the  development  of  a  new  weapon  system.  This  includes 
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functions  such  as  program  management,  systems  engineering,  financial  transactions,  contracting 
actions,  etc. 

The  final  swim  lane  or  fifth  swim  lane  is  titled  Contractors.  This  swim  lane  is  where  the  actual 
work  is  usually  done;  ideas  are  translated  into  products  or  systems,  and  ultimately  this  work  is  delivered 
to  the  government  for  approval. 

Visually,  the  model  is  depicted  in  Figure  22:  Model  Scope  in  Relation  to  the  Overall  Acquisition 
System  in  Chapter  5.  In  the  representation  of  this  model,  the  swim  lanes  are  horizontal  and  the  vertical 
lines  represent  integrating  activities  that  occur  across  all  the  swim  lanes.  These  integrating  events  are 
called  milestones  as  defined  by  the  acquisition  system.  For  a  successful  program  to  go  from  idea  to 
delivery  in  the  hands  of  the  war  fighter,  successful  navigation  and  integration  of  all  of  these  processes 
must  take  place.  The  milestones  are  designed  to  play  a  key  role  in  the  successful  delivery  of  the  systems 
and  bear  resemblance  to  commercial  stage-gate  product  development  reviews. 

The  swim  lanes  also  have  differing  assumptions  as  well  as  modes  of  operation.  For  instance,  the 
user  and  the  requirements  swim  lanes  are  discrete  in  nature  while  the  programming  and  budgeting 
swim  lane  is  continuous  in  nature.  The  acquisition  and  contracting  swim  lanes  are  a  combination  of 
continuous  and  discrete  activities. 

For  the  purposes  of  this  dissertation,  and  to  manage  the  scope  of  this  project,  the  user  swim 
lane  will  not  be  included  in  the  detailed  representation  of  the  model.  Also,  any  detailed  definition  of  the 
model  beyond  Milestone  C  will  not  be  done.  At  Milestone  C,  approval  is  given  for  the  acquisition  system 
to  enter  into  production.  By  the  time  production  has  started,  most  of  the  major  developmental 
decisions  have  already  been  made.  Any  addition  or  change  to  the  current  system  will  likely  be  handled 
under  an  engineering  change  proposal  process  by  the  organization  that  will  most  likely  be  responsible 
for  the  sustainment  of  the  system,  or  the  change  will  be  redirected  back  through  the  entire  formalized 
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acquisition  system.  These  are  some  of  the  reasons  why  the  model  is  not  developed  further  and 
activities  in  these  areas  are  not  included. 

The  main  outputs  of  the  model  are  the  time  and  cost  of  a  program.  The  mathematics  behind 
the  model  is  quite  simple  and  straightforward.  The  model  uses  probabilities  and  curve-fitting  methods 
to  address  uncertainty  and  probabilities.  The  actual  sources  of  these  uncertainties  and  probabilities 
come  from  experts  in  the  field  that  "live"  in  this  process  from  day  to  day.  For  example,  typical 
uncertainties  would  be  the  time  duration  associated  with  a  given  task.  In  those  cases,  usually  a  range  of 
days  was  given,  with  the  additional  information  of  the  most  likely  outcome.  This  allowed  the  use  of  a 
triangular  distribution59  to  be  used  in  the  mathematical  modeling.  The  time  elapsed  for  a  program  is 
then  simply  the  cumulative  value  of  the  number  of  days  required  to  go  through  the  overall  system.  The 
costs  of  the  system  will  be  changed  at  various  places  according  to  a  few  standing  rules  and  heuristics, 
also  derived  from  the  interviews,  such  as  add  1%  to  contract  value  at  this  point  in  the  process. 

Project  Attributes 

The  unit  of  analysis  in  this  model  is  the  individual  project  or  program.  In  order  to  initialize  the 
model,  there  are  several  attributes  that  will  be  associated  with  each  program.  Some  of  these  are 
artifacts  of  the  model  itself;  trackers  and  counters  to  maintain  a  sense  of  place  within  the  model;  others 
are  related  to  the  actual  outcomes  measures,  such  as  cost  and  schedule  of  the  project. 

Unit  of  Measurement 

As  mentioned  earlier,  the  model's  unit  of  measurement  is  the  program.  A  program  may  consist 
of  only  one  or  multiple  projects  that  eventually  will  result  in  a  delivered  item.  Multiple  programs  may 
contribute  key  parts  to  an  overall  system.  For  example,  the  B-2  System,  as  of  2009,  has  four  different 
programs  associated  with  it.  Two  of  the  programs  are  designated  ACAT  Level  III  and  two  are  designated 

59  In  some  cases,  a  binomial  model  is  used  and  as  required,  extrapolated  into  a  triangular  distribution  to  match  the 
constraints  of  the  modeling  environment. 
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ACAT  Level  1C.  However,  the  F-22,  as  of  2009,  has  just  one  program  and  it  is  designated  ACAT  Level  ID. 


Within  each  of  those  programs  can  be  multiple  projects,  working  on  a  particular  sub-system  or 
component.  Regardless  of  the  confusion  this  might  cause,  for  purposes  of  this  model,  the  main  unit  of 
measurement  will  be  the  program. 

For  purposes  of  model  definition,  verification  and  validation,  several  programs  of  differing  sizes 
and  time  durations  will  be  used.  The  rough  outlines  of  these  programs  will  be  broken  down  according  to 
ACAT  levels  as  there  is  a  strong  probability  that  different  ACAT  levels  result  in  different  levels  of 
attention  and  scrutiny,  translating  into  possible  differences  in  time  distributions  and  decision 
probabilities. 

As  the  model  is  tested  and  validated,  these  differences  will  be  explored  and  a  final 
determination  made  prior  to  coding  the  model  in  a  computer  program.  When  the  model  is  coded, 
different  techniques,  such  as  Monte  Carlo  simulations  will  be  used  to  find  the  range  of  all  possible 
outcomes  as  well  as  a  determination  as  to  how  many  runs,  samples,  etc.,  need  to  be  accomplished  to 
develop  confidence  in  the  data  outcomes.  Chapter  6  discusses  this  process  in  great  detail. 
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ACAT  Discussion 


As  a  brief  reminder,  here  are  the  ACAT  level  definitions  and  the  ones  that  will  be  used  to 
differentiate  between  programs.  DOD  5002,  Enclosure  E  states  "A  technology  project  or  acquisition 
program  shall  be  categorized  based  on  its  location  in  the  acquisition  process,  dollar  value,  and  MDA 
special  interest"  [148],  The  following  table  is  from  DOD  5002  describing  the  different  ACAT  levels  [148], 

Table  E2.T1.  Description  and  Decision  Authority  for  ACAT  I  -  III  Programs 


Acquisition 

Category 

Reason  for  ACAT  Designation 

Decision  Authority 

ACAT  1 

•  MDAP  (10  USC  2430,  reference  (n))) 

o  Dollar  value:  estimated  by  the 

USD(AT&L)  to  require  an  eventual  total 
expenditure  for  research,  development, 
test  and  evaluation  (RDT&E)  of  more 
than  $365  million  in  fiscal  year  (FY)  2000 
constant  dollars  or,  for  procurement,  of 
more  than  $2,190  billion  in  FY  2000 
constant  dollars 
o  MDA  designation 

•  MDA  designation  as  special  interest 

ACAT  ID:  USD(AT&L) 

ACAT  1C:  Head  of  the  DOD 
Component  or,  if 
delegated,  the  DOD 
Component  Acquisition 
Executive  (CAE) 

ACAT  IA 

•  MAIS:  Dollar  value  of  AIS  estimated  by  the  DOD 
Component  Flead  to  require  program  costs  (all 
appropriations)  in  any  single  year  in  excess  of 
$32  million  in  fiscal  year  (FY)  2000  constant 
dollars,  total  program  costs  in  excess  of  $126 
million  in  FY  2000  constant  dollars,  or  total  life- 
cycle  costs  in  excess  of  $378  million  in  FY  2000 
constant  dollars 

•  MDA  designation  as  special  interest 

ACAT  1AM:  ASD  (C3l)/DOD 
CIO 

ACAT  IAC:  CAE,  as 
delegated  by  the  DOD  CIO 

ACAT  II 

•  Does  not  meet  criteria  for  ACAT  1 

•  Major  system 

o  Dollar  value:  estimated  by  the  DOD 
Component  Flead  to  require  an  eventual 
total  expenditure  for  RDT&E  of  more 
than  $140  million  in  FY  2000  constant 
dollars,  or  for  procurement  of  more 
than  $660  million  in  FY  2000  constant 

DOD  CAE  or  the  individual 
designated  by  the  CAE 
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dollars  (10  USC  2302d,  reference  (o)) 
o  MDA  designation  4  (10  USC  2302(5), 
reference  (p)) 

•  MDA  designation  as  special  interest 


ACAT 


Does  not  meet  criteria  for  ACAT 
Less-than  a  MAIS  program 


or  above 


Designated  by  the  DOD 
CAE  at  the  lowest  level 
appropriate 


Notes: 


•  In  some  cases,  an  ACAT  IA  program,  as  defined  above,  also  meets  the  definition  of  an  MDAP.  The 
USD(AT&L)  and  the  ASD(  C3I  )/DOD  CiO  shall  decide  who  will  be  the  MDA  for  such  programs. 
Regardless  of  who  is  the  MDA,  the  statutory  reguirements  that  apply  to  MDAPs  shall  apply  to  such 
programs. 

•  An  AIS  program  is  an  acquisition  program  that  acquires  IT,  except  IT  that  involves  equipment  that  is 
an  integral  part  of  a  weapon  or  weapons  system,  or  is  an  acquisition  of  services  program. 

•  The  ASD  (C3I  )/DOD  CIO  shall  designate  programs  as  ACAT  1AM  or  ACAT  IAC.  MAIS  programs  shall 
not  be  designated  as  ACAT  II. 

•  As  delegated  by  the  Secretary  of  Defense  or  Secretary  of  the  Military  Department. 


Table  51:  Description  and  Decision  Authority  for  ACAT  I  -  III  Programs 


Additionally,  there  is  some  confusion  about  when  an  ACAT  level  is  determined. 


"Selection  of  the  Milestone  Decision  Authority  (MDA)  occurs  during  the  capabilities  generation 
process.  A  potential  ACAT  designation  is  indicated  on  the  Initial  Capabilities  Document  per 
CJCSM  3170. 01B,  along  with  the  MDA.  Approval  of  this  document  is  required  prior  to  the 
Concept  Decision.  The  potential  ACAT  is  determined  based  on  an  assessment  of  cost, 
complexity,  and  risk  (may  be  very  much  an  estimate  of  all  three).  Even  though  alternatives  are 
being  looked  at,  it  may  be  apparent  whom  the  proper  MDA  should  be.  The  formal  designation  is 
made  when  the  Capabilities  Development  Document  is  approved.  Some  large  and  of  interest 
programs  are  placed  on  a  pre-MDAP  list  by  DOD  prior  to  MS  B"  [149bold  text  added]. 

This  model  therefore  makes  an  assumption  from  the  very  beginning  what  the  ACAT  level  of  a 

program  will  be.  Based  on  the  above  quote  from  the  Defense  Acquisition  University  Knowledge  Sharing 


System  website,  this  assumption  is  reasonable. 


The  Programming,  Planning,  Budgeting  and  Execution  Process 

The  Budgeting  and  Programming  swim  lane  will  be  discussed  separately  from  the  rest  of  the 
model.  It  is  a  continuous  process  and  is  the  most  structured  and  defined  of  any  of  the  swim  lanes  under 
consideration.  It  is  reasonable  to  call  the  swim  lane  the  drum  by  which  all  others  must  march.  It  gives  a 
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rough  duration  of  a  "takt"  time  for  the  overall  system  as  all  other  swim  lanes  must  work  with  and 
around  the  processes  within  this  swim  lane. 

Through  the  modeling  activity  for  the  entire  system,  it  became  apparent  that  interviewees  and 
other  sources  already  mentally  reckoned  for  the  operation  of  the  PPBE  juxtaposed  against  the  activities 
of  an  individual  program.  Therefore,  the  formal  model  used  in  the  dissertation  research  accounts  for 
the  PPBE  vagaries  through  several  surrogate  tasks  and  decisions.  These  surrogates  are  more  likely  to  be 
"event"  driven  and  serve  to  cause  delays,  etc.,  until  proper  alignment  can  be  reached  with  the  PPBE.  The 
purpose  of  the  description  of  this  portion  of  the  larger  Acquisition  system  is  to  familiarize  the  reader 
with  the  overall  structure  of  the  PPBE  as  well  as  the  complexity  involved.  A  high  level  description  of  the 
PPBE  occurs  in  Chapter  2. 

Budgeting  and  Programming  Swim  Lane 


lowest  level  possible  -  that  of  a  MAJCOM  planning  activity.  Oftentimes,  this  process  will  begin  two  and 
one-half  or  more  years  prior  to  the  actual  enactment  of  the  budget  into  law.  And,  since  the  process 
duration  is  at  least  two  years,  the  "start"  of  each  cycle  begins  each  year.  To  better  understand  the 
reality  of  these  policies,  a  "new  start"  budget  request  means  that  approximately  two  and  one-half  years 
prior  to  the  money  being  available  to  be  spent,  a  budget  request  must  be  made.  As  many  players 
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attempt  to  synchronize  the  availability  of  funding  to  do  work,  it  requires  a  great  deal  of  prognosticative 


ability  to  estimate  the  budget  correctly  for  the  "new  start".  However,  the  ability  and  likelihood  of  being 
able  to  'adjust'  these  budget  numbers  in  the  future  is  high.  A  program's  "schedule  is  like  an  accordion 
to  get  alignment  with  the  actual  PPBE"  (PPBE  Participant).  The  first  major  assumption  made  in  this  swim 
lane  is  that  both  the  odd  and  even  years  are  going  to  be  modeled  the  same,  but  the  official  outcomes 
may  have  different  names  even  though  functionally  they  are  the  same. 


Figure  54:  First  third  of  PPBE  model 

The  "first"  task  within  the  Budgeting  and  Programming  swim  lane  is  "Advanced  Concepts  Budget 
Request".  See  figure  above.  This  organization  is  just  one  of  many  competing  for  the  resources  in  the  AF 
Budget.  It  coordinates  with  the  Requirements  branch  regarding  the  information  of  a  potential  new 
program.  In  the  Pre-MS  A  phase,  the  main  activity  is  planning  the  resources  required  for  the  initial 
studies  to  support  the  development  of  the  ICD  and  later,  if  required,  the  Analysis  of  Alternatives 
required  to  develop  the  draft  CCD.  The  further  a  program  is  along  in  its  development  and  declared 
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milestone,  the  more  definition  and  certainty  accompanies  these  budget  requests.  As  this  organization 


has  many  activities  going  on  at  any  given  time,  it  is  balancing  many  competing  interests  and  ideas  and 
limited  resources.  This  task  requires  approximately  30  to  35  days  to  bring  everything  together.  Its 
distribution  is  binomial,  p=0.7.  The  source  of  this  information  comes  from  various  published  timelines 
and  documents  outlining  the  overall  process. 

A  decision  task  entitled  "MAJCOM  PEM  Decision  to  pursue"  has  a  probability  of  95%.  See  figure 
above.  This  probability  is  due  to  the  active  steps  being  taken  to  develop  a  requirements  document  and 
the  other  activities  going  on  at  any  given  time  within  the  Requirements  branch.  The  idea  is  to  support 
as  many  initiatives  as  possible.  The  next  time  an  idea  goes  through  the  process,  the  probability  rises  to 
99%  (ergo,  the  program  is  in  development  and  has  already  passed  a  first  round  of  scrutiny  going  up  to 
the  highest  levels  of  the  AF.  The  source  of  this  information  comes  from  interviews. 

A  process  task  entitled  "MAJCOM  Panel"  has  a  time  distribution  of  30  to  35  days.  See  the  figure 
above.  Its  distribution  is  also  binomial,  p=0.7.  The  source  of  this  information  comes  from  interviews 
and  source  documents  outlining  the  process  flow.  At  the  Panel,  the  idea/program/activity  competes 
with  all  of  the  other  items  for  the  piece  of  resources  that  is  under  the  purview  of  the  panel.  The  panels 
are  typically  given  a  "bogey"  to  meet.  Choices  have  to  be  made  between  existing  programs  versus  new 
programs.  It  is  a  balancing  act.  Typically  there  are  several  categories  used  to  discriminate  the  funding: 
"hold",  "new",  "reduce".  Any  program  that  is  a  "Chief's  program,"  e.g.  a  program  with  a  personal 
advocate  being  the  Chief  of  Staff  or  any  4-star  general,  gets  a  "free-pass"  at  this  stage.  Stoplight  charts 
are  used  focusing  on  items  such  as  spending  rates,  funding  profiles,  health  of  the  overall  program,  etc. 
There  are  two  measuring  sticks  for  programs:  Criticality  (1  =  "AF  driven"  through  5  =  "Outside 
influence")  and  Radioactivity  (A  =  "the  world  will  end"  through  D  =  "lowest  level  of  concern").  The  "risk" 
to  an  upcoming  Milestone  plays  heavily  in  these  deliberations.  The  Panel  deliberation  time  is  very 
stringent. 
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A  decision  point  entitled  "Change?"  has  a  probability  of  50%.  However,  if  the  idea  has 


previously  been  approved,  the  probability  drops  to  5%.  This  step  captures  the  outcome  of  the  panel 
process,  being  approved  or  denied  funding.  Again,  the  values  associated  with  this  process  indicate  the 
synergy  of  multiple  activities  going  forward,  reflecting  information  from  the  requirements  branch  in 
particular  and  other  stakeholders.  However,  to  be  more  specific,  we  need  to  determine  what  happened 
to  the  project  if  it  did  get  changed.  The  first  question  to  ask  is  if  the  program  was  killed.  The  probability 
of  this  step  is  5%.  If  the  project  has  been  through  the  process  before,  the  probability  decreases  to  1%.  If 
the  program  is  not  killed,  the  next  question  asked  is  if  the  program  received  a  funding  cut.  The  probably 
of  this  step  is  99%.  Regardless  of  the  outcome,  information  about  the  change  is  transmitted  to  other 
processes  outside  of  the  swim  lane  that  have  an  interest  in  the  program. 
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A  process  task  entitled  "MAJCOM  group"  has  a  time  distribution  of  30  to  35  days.  See  the  figure 


above  to  see  its  relationship  to  the  other  PPBE  processes.  Its  distribution  is  binomial,  p=0.7.  As  the 
MAJCOM  Panel  before,  this  group  has  a  larger  slice  of  resources  to  distribute  and  combines  the  inputs  of 
several  panels.  Some  adjustments  are  made  in  the  panel  submissions  based  on  new  information, 
changing  priorities,  etc.  The  source  of  this  information  is  from  an  interview,  official  documents  and 
published  timelines. 

A  decision  point  entitled  "Change?"  has  a  probability  of  40%.  If  the  idea  has  previously  been 
approved,  the  probability  drops  to  10%.  This  step  captures  the  outcome  of  the  panel  process,  being 
approved  or  denied  funding.  Again,  the  values  associated  with  this  process  indicate  the  synergy  of 
multiple  activities  going  forward,  reflecting  information  from  the  requirements  branch  in  particular  and 
other  stakeholders.  However,  to  be  more  specific,  we  need  to  determine  what  happened  to  the  project 
if  it  did  get  changed.  The  first  question  to  ask  is  if  the  program  was  killed.  The  probability  of  this  step  is 
5%.  If  the  project  has  been  through  the  process  before,  the  probability  decreases  to  1%.  If  the  program 
is  not  killed,  the  next  question  asked  is  if  the  program  received  a  funding  cut.  The  probably  of  this  step 
is  99%.  Regardless  of  the  outcome,  information  about  the  change  is  transmitted  to  other  processes 
outside  of  the  swim  lane  that  have  an  interest  in  the  program. 

A  process  task  entitled  "MAJCOM  Council"  has  a  time  distribution  of  30  to  35  days.  See  the 
figure  above.  Its  distribution  is  binomial,  p=0.7.  As  the  MAJCOM  group  before,  the  council  has  the 
responsibility  to  integrate  all  of  the  MAJCOM  resources  into  a  coherent  budget  request.  Some 
adjustments  are  made  in  the  council  recommendations  based  on  new  information,  changing  priorities, 
etc.  The  source  of  this  information  is  from  an  interview,  official  documents  and  published  timelines. 

A  decision  point  entitled  "Change?"  has  a  probability  of  30%.  If  the  idea  has  previously  been 
approved,  the  probability  drops  to  15%.  This  step  captures  the  outcome  of  the  panel  process:  being 
approved  or  denied  funding.  Again,  the  values  associated  with  this  process  indicate  the  synergy  of 
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multiple  activities  going  forward,  reflecting  information  from  the  requirements  branch  in  particular  and 


other  stakeholders.  However,  to  be  more  specific,  there  is  a  need  to  determine  what  happened  to  the 
project  if  it  did  get  changed.  The  first  question  asked  is  if  the  program  was  killed.  The  probability  of  this 
step  is  15%.  If  the  project  has  been  through  the  process  before,  the  probability  decreases  to  1%.  If  the 
program  is  not  killed,  the  next  question  asked  is  if  the  program  received  a  funding  cut.  The  probably  of 
this  step  is  99%.  Regardless  of  the  outcome,  information  about  the  change  is  transmitted  to  other 
processes  outside  of  the  swim  lane  that  have  an  interest  in  the  program.  All  of  the  process  steps  and 
proposed  timelines  prior  to  this  point  come  from  an  Air  Combat  Command  Presentation  [111],  The 
activity  runs  from  mid-August  through  mid-December. 

After  these  processes  occur,  there  is  very  little  control  that  the  sponsor  has  over  the  program  in 
question.  In  this  case,  other  factors  come  into  play.  For  instance,  if  a  program  will  be  done  within 
budget  and  on  schedule  in  four  years,  but  the  AF  doesn't  need  it  for  six,  the  program  will  have  its 
funding  cut  to  delay  it  by  two  years  until  it  is  needed.  The  same  is  true  for  interdependencies.  If 
another  program  is  required  for  something  to  work,  but  it  has  been  delayed,  all  programs  that  are 
connected  with  this  program  will  be  heavily  scrutinized  to  see  if  "savings"  can  be  achieved  by  cutting 
budgets  now,  e.g.  in  order  to  delay  all  of  these  systems,  until  the  time  that  they  are  needed.  The  next 
process  depicted  in  the  figure  above  is  where  this  scrutiny  happens  the  most.  In  fact,  while  the  sponsor 
spends  a  tremendous  amount  of  time  defending  their  programs,  they  are  often  bystanders  in  the 
process. 

A  process  task  called  "AF  level  process"  has  a  time  length  of  210  -  225  days.  Its  distribution 
shape  is  binomial,  p=0.7.  This  is  the  first  major  abstraction  in  the  budgeting  and  programming  process. 
The  AF  has  a  similar  process  to  the  MAJCOM  process  with  panels,  groups,  and  the  council.  This  is 
described  in  detail  in  the  section  of  Chapter  2  entitled  PPBE.  In  this  case  the  product  is  the  overall  AF 
budget  request.  As  the  budget  is  being  finalized,  changes  to  various  programs  are  inevitable.  In  reality, 
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OSD  is  running  several  activities  in  parallel.  Right  now  all  of  these  are  accounted  for  in  this  process.  The 


PEM  that  is  in  the  first  process  step  is  constantly  following  the  progress  of  "their"  particular  program 
and  championing  it's  survival  through  the  entire  process.  This  is  a  full-time  activity  for  the  PEM.  The 
source  of  this  information  is  interviews,  official  documents,  and  published  timelines. 

A  decision  point  entitled  "Change?"  has  a  probability  of  35%.  If  the  idea  has  previously  been 
approved,  the  probability  drops  to  15%.  This  step  captures  the  outcome  of  the  panel  process,  being 
approved  or  denied  funding.  Again,  the  values  associated  with  this  process  indicate  the  synergy  of 
multiple  activities  going  forward,  reflecting  information  from  the  requirements  branch  in  particular  and 
other  stakeholders.  However,  to  be  more  specific,  there  is  a  need  to  determine  what  happened  to  the 
project  if  it  did  get  changed.  The  first  question  to  ask  is  if  the  program  was  killed.  The  probability  of  this 
step  is  15%.  If  the  project  has  been  through  the  process  before,  the  probability  decreases  to  1%.  If  the 
program  is  not  killed,  the  next  question  asked  is  if  the  program  received  a  funding  cut.  The  probably  of 
this  step  is  99%.  Regardless  of  the  outcome,  information  about  the  change  is  transmitted  to  other 
processes  outside  of  the  swim  lane  that  have  an  interest  in  the  program. 

A  process  task  called  "Programming  issues  and  Budgeting  Hearings"  has  a  time  length  of  60  -  75 
days  and  is  depicted  in  the  figure  above.  The  process  has  a  time  distribution  that  is  binomial,  p=0.70. 
This  is  another  major  abstraction  in  the  budgeting  and  programming  process.  OSD  is  involved  and  has 
its  own  process  for  determining  the  OSD  budget  request.  In  this  case  the  product  is  the  DOD  POM  and 
any  Program  Decision  Memorandums  (PDMs).  As  the  budget  is  being  finalized,  changes  to  various 
programs  are  inevitable;  PDMs  document  the  major  program  issues.  A  PDM  is  an  official 
acknowledgement  of  a  change  to  a  program's  budget  request  and  documents  the  decisions  made.  The 
PDM  is  used  by  Acquisition  to  plan  the  program  expenditures  over  time.  Furthermore,  many  budgeting 
issues  are  going  on  like  hearings  and  formal  questions  between  the  DOD  and  other  government 
branches.  The  source  of  this  information  is  interviews,  official  documents,  and  published  timelines. 
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Figure  56:  Last  third  of  PPBE  model 

A  decision  point  named  "PDM?"  has  a  probability  of  100%  for  being  "no"  the  first  time  through 
the  process  and  remains  that  way  until  after  MS  B  is  reached  and  it  is  an  official  "program  of  record"; 
afterwards,  there  is  a  5%  probability  of  being  "yes".  If  yes,  the  outcome  triggers  the  start  of  the 
"Prepare  Courses  of  Action"  process  task  within  the  Acquisition  swim  lane.  This  decision  point  is 
interesting  as  is  it  possible  that  no  PDM  is  ever  issued  yet  the  program  does  not  survive  the  budget 
process  within  DOD. 

If  "no",  a  decision  point  entitled  "Change  DOD  POM  is  reached."  It  has  a  probability  of  30%.  If 
the  idea  has  previously  been  approved,  the  probability  drops  to  15%.  This  step  captures  the  outcome  of 
the  process:  being  approved  or  denied  funding.  Again,  the  values  associated  with  this  process  indicate 
the  synergy  of  multiple  activities  going  forward,  reflecting  information  from  the  requirements  branch  in 
particular  and  other  stakeholders.  However,  to  be  more  specific,  there  is  a  need  to  determine  what 
happened  to  the  project  if  it  did  get  changed.  The  first  question  to  ask  is  if  the  program  was  killed.  The 
probability  of  this  step  is  10%.  If  the  project  has  been  through  the  process  before,  the  probability 
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decreases  to  1%.  This  is  again  due  to  the  pressures  and  momentum  that  an  existing  program  already 


has  at  all  stages  of  the  program.  If  the  program  is  not  killed,  the  next  question  asked  is  if  the  program 
received  a  funding  cut.  The  probably  of  this  step  is  99%.  Regardless  of  the  outcome,  information  about 
the  change  is  transmitted  to  other  processes  outside  of  the  swim  lane  that  have  an  interest  in  the 
program.  The  source  of  this  information  is  an  interview  as  well  as  published  documents  and  timelines. 

A  process  task  entitled  "OSD"  has  a  time  distribution  of  30  -  45  days.  Please  see  the  figure 
above  to  determine  its  relationship  to  the  other  PPBE  tasks  and  processes.  Its  distribution  is  binomial, 
p=0.7.  This  is  another  major  abstraction  in  the  budgeting  and  programming  process.  OSD  works  closely 
with  the  other  services  resolving  issues  that  have  come  up  in  the  other  programming  and  budgeting 
phases.  In  this  case,  the  product  is  the  final  BES,  Budget  Estimate  Submission  and  any  Program  Budget 
Decisions  (PBDs).  A  PBD  is  an  official  acknowledgement  of  a  change  to  a  program's  budget  request  due 
to  execution  issues  and  documents  the  decisions  made.  As  the  budget  is  being  finalized,  issues 
occasionally  arise  due  to  current  programs  having  problems  executing  their  budgets;  PBDs  document 
these  decisions  about  execution  issues.  The  PBD  is  used  by  Acquisition  to  plan  the  program 
expenditures  over  time.  The  source  of  this  information  is  interviews,  official  documents,  and  published 
timelines. 

A  decision  point  named  "PBD?"  has  a  probability  of  100%  for  being  "no"  the  first  time  through 
the  process;  afterwards,  there  is  a  5%  probability  of  being  "yes".  Please  see  the  figure  above.  If  yes,  the 
outcomes  triggers  the  start  of  the  "Prepare  Courses  of  Action"  process  task  within  the  Acquisition  swim 
lane.  This  decision  point  is  interesting  as  is  it  possible  that  no  PBD  is  ever  issued  yet  the  program  does 
not  survive  the  budget  process  within  the  executive  branch. 

If  "no",  a  decision  point  entitled  "Change  BES?"  is  reached.  It  has  a  probability  of  20%.  If  the 
idea  has  previously  been  approved,  the  probability  drops  to  5%.  If  the  idea  has  previously  been 
approved  but  the  PBD  step  was  answered  "yes",  this  probability  increases  to  50%.  This  step  captures 
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the  outcome  of  the  process:  being  approved  or  denied  funding.  Again,  the  values  associated  with  this 


process  indicate  the  synergy  of  multiple  activities  going  forward,  reflecting  information  from  the 
requirements  branch  in  particular  and  other  stakeholders.  However,  to  be  more  specific,  there  is  a  need 
to  determine  what  happened  to  the  project  if  it  did  get  changed.  The  first  question  to  ask  is  if  the 
program  was  killed.  The  probability  of  this  step  is  5%.  If  the  project  has  been  through  the  process 
before,  the  probability  decreases  to  1%.  This  is  again  due  to  the  pressures  and  momentum  that  an 
existing  program  already  has  at  all  stages  of  the  program.  If  the  program  is  not  killed,  the  next  question 
asked  is  if  the  program  received  a  funding  cut.  The  probably  of  this  step  is  99%.  Regardless  of  the 
outcome,  information  about  the  change  is  transmitted  to  other  processes  outside  of  the  swim  lane  that 
have  an  interest  in  the  program.  The  source  of  this  information  is  an  interview  as  well  as  published 
documents  and  timelines,  in  particular,  the  online  Chapter  1.2  of  the  Defense  Acquisition  Guidebook, 
"Planning,  Programming,  Budgeting  and  Execution  (PPBE)  Process"  [150], 

A  process  task  named  "Congress"  has  a  time  distribution  of  240  to  330  days.  Its  distribution  is 
binomial,  p=0.7.  This  task  includes  the  processes  going  on  in  the  Executive  Branch's  Office  of 
Management  and  Budget  as  well  as  the  deliberations  done  by  Congress.  Officially,  the  time  allotted  for 
passage  of  the  next  budget  ends  on  30  September,  but  Congress  has  a  poor  track  record  of  completing 
its  work  on  time.  Usually,  when  they  haven't  finished  their  work  on  time,  a  Continuing  Resolution  is 
passed,  giving  the  government  authority  to  spend  at  90%  of  last  year's  levels  on  existing  programs  only. 
To  account  for  the  possibility  of  this  happening,  a  time  distribution  is  allotted  for  a  process  that  should 
be  a  time-driven,  defined  event.  The  model  will  treat  this  step  as  one  that  must  be  finished  before  the 
first  contractor  work  can  begin.  After  that,  delays  past  the  720-day  "cycle"  could  trigger  the  step  in  the 
Acquisition  swim  lane,  "Prepare  Courses  of  Action",  to  adjust  for  the  unexpected  delays  and  assess 
program  impacts.  The  source  of  this  information  is  public  records. 
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A  decision  task  named  "law"  captures  the  chance  that  a  program  might  be  removed  entirely  by 


Congress.  Please  see  the  figure  above.  The  probability  of  this  happening  is  approximately  3%  or  there  is 
a  97%  chance  the  program  emerges  through  Congress.  The  source  of  this  information  is  experience  and 
intuition. 

A  decision  task  named  "Changes  to  BES?"  reflects  the  strong  possibility  that  Congress  may  in 
fact  change  the  requested  amounts.  Most  of  these  changes  occur  during  the  mark-up  process  during 
Congress.  The  probability  of  this  happening  is  35%.  If  "yes",  this  triggers  the  "Prepare  Courses  of 
Action"  task  in  the  Acquisition  Swim  Lane.  Regardless  of  outcomes,  another  task  entitled  "Release 
moneys  to  Acquisition"  has  a  time  distribution  of  15  to  35  days.  Please  see  the  figure  titled  "Middle 
third  of  PPBE  model."  Its  distribution  is  binomial,  p=0.7.  The  distribution  reflects  the  time  required  for 
the  money  to  be  dispersed  to  the  lower  levels  of  the  Air  Force  and  the  actual  office  responsible  for 
spending  the  money  through  contracting  actions.  The  source  of  this  information  is  based  upon 
experience  and  common  understanding  of  how  moneys  flow  through  the  system. 

The  path  of  any  "no"  branch  from  the  "next  step",  "DOD  POM",  "BES",  and  "law"  goes  to 
another  decision  point,  "Retry"  with  a  probability  of  99%.  Please  see  the  figure  titled,  "First  third  of 
PPBE  model."  The  reason  for  the  high  percentage  is  that  most  of  these  ideas  will  simply  end  up  on  a 
"wish  list"  of  some  kind  that  is  vying  for  resources.  Over  time,  the  object  of  these  efforts  to  gain 
resources  of  some  kind  will  be  successful.  The  path  as  depicted  in  the  figures  is  to  go  through  the  entire 
process  again,  but  in  actuality,  the  budget  request  step  is  re-prepared  within  7  days  (1  to  7  days).  This 
step  has  a  binomial  distribution,  p=0.4.  The  MAJCOM  PEM  decision  point  is  also  repeated  and  then  is 
directly  inserted  into  the  process  step  that  is  currently  on-going  as  long  as  it  stays  within  the  MAJCOM 
process.  However,  if  the  rejecting  step  was  at  the  AF  level,  the  system  will  have  to  wait  until  the  next 
budget  process  begins  with  all  of  the  same  probabilities  and  time  durations.  Otherwise,  a  "no"  at  the 
PEM  decision  point  will  go  to  an  archive  and  the  model  ends  at  this  point  for  this  idea. 
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This  "overall"  process  will  continue  throughout  the  execution  and  delivery  of  the  overall 


program.  By  definition,  it  repeats  itself  and  interacts  with  programs  and  other  aspects  of  the  Acquisition 
system  at  whatever  point  in  the  development  of  a  program  it  needs  to.  For  the  purposes  of 
understanding  the  Acquisition  system,  the  PPBE  model  constitutes  a  stand-alone  component  of  the 
overall  system.  It  is  instructive  and  useful  to  understand  the  dynamics  involved  in  building  the  budget, 
but  the  uncertainties  are  already  accounted  for  in  the  overall  workings  of  the  model,  as  discussed 
earlier.  The  PPBE  model,  as  described  above,  was  validated  by  a  PPBE  participant  working  within  AF/A5. 

Detailed  Model  Explanation 

The  following  pages  will  contain  a  more  detailed  breakdown  of  the  contents  and  processes 
defining  the  other  swim  lanes.  Each  swim  lane  consists  of  multiple  activities  characterized  by  tasks  with 
a  corresponding  time  distribution  and  decisions  accompanied  by  probabilities.  As  these  tasks  and 
decisions  are  strung  together,  the  overall  workings  of  each  swim  lane  can  be  approximated. 

The  detailed  breakdown  will  also  include,  at  each  process  task  and  decision  point,  information 
regarding  its  time  distribution,  if  it  is  a  process,  or  its  probability,  if  it  is  a  decision.  Other  model 
elements  that  exist  to  assist  in  the  operation  of  the  model  will  be  discussed  as  well.  Additionally,  the 
source  or  the  rationale  for  choosing  this  information  and  any  additional  heuristics  that  may  or  may  not 
be  followed  will  be  given.  An  example  of  the  potential  for  heuristics  that  might  be  followed  include 
different  time  distributions  depending  upon  its  political  import,  the  magnitude,  cost,  or  schedule 
associated  with  a  particular  project,  or  differing  time  distributions  depending  on  how  many  times  a 
particular  activity  has  gone  through  this  process  before,  or  where  other  scenarios  or  scenario-based 
events  would  cause  these  distributions  to  change.  The  same  would  also  hold  true  for  the  probabilities 
associated  with  decision  points. 
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Figure  57:  Final  Model  Representation 

As  mentioned  earlier  in  Chapter  5,  the  model  above  is  a  representation  or  an  abstraction  of  the 
overall  Acquisition  system.  The  following  figure  attempts  to  highlight  some  of  key  sections  represented 
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in  graphical  model  used  in  the  research.  Please  note  how  the  different  swim  lanes  are  labeled  as  well  as 
the  key  phases,  e.g.  Pre-MS  A,  Pre-MS  B,  and  Pre-MS  C,  are  identified. 


Informal  entry 
processes  and 
screening 

Requirement^ 
approvals 
(MAJCOM) 

Joint  requiremej 
approvals 

Acquisition 
Panels 

Systems 
Engineering 
reviews  and 
testing 


Figure  58:  Final  model  with  descriptive  labels 

Through  the  remainder  of  this  appendix,  various  sections  of  the  model  will  be  identified  and 


shown  with  a  close-up  view. 


The  Pre-Milestone  A  Swim  Lanes 

The  following  section  will  go  into  details  on  the  Pre-Milestone  A  swim  lane.  It  will  break  down 
the  sections  into  legible  pieces  that  will  allow  the  reader  to  fully  understand  the  model's  construction. 
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The  figure  above  indicates  which  figure  to  refer  to  in  order  to  get  detailed  model  information  on 
specific  sections  of  the  model.  The  detailed  explanation  for  the  content  within  the  figure  will 
immediately  follow  the  figure. 


The  entry  point  into  the  entire  model  as  well  as  the  requirements  swim  lane  consists  of  a  simple 
starting  point  called  "Start  Model."  The  item  entitled  "Assign  Beginning  simulation  time"  is  to  facilitate 
bookkeeping  within  the  model,  e.g.  an  artifact  of  the  model  and  not  the  overall  process.  The  real  entry 
point  is  simulated  with  a  random  process  with  a  time  distribution  anywhere  from  1  to  365  days.  This  is 
titled  "Random  Entry  Point."  This  condition  simulates  the  dynamic  nature  of  ideas  and  requests  coming 
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into  the  requirements  system  at  any  time  during  the  year.  This  information  was  validated  by  individuals 


who  work  in  the  requirements  system.  There  are  no  distinct  trends  that  determine  when  an  idea  arrives 
for  their  disposition.  The  interesting  thing  about  this  time  distribution  is  that  it  does  impact  how  and 
when  an  idea  is  pushed  into  other  systems.  For  instance,  something  that  comes  in  the  middle  or  the 
later  end  of  the  year  will  most  likely  not  make  it  into  the  following  year's  financial  deliberations.  Of 
course,  there  are  always  exceptions  to  the  rule,  particularly  if  they  find  this  particular  idea  to  have  a  lot 
of  potential,  or  it  has  some  political  implications  that  need  to  be  addressed  immediately.  However,  for 
the  purposes  of  this  model,  we  are  going  to  assume  that  these  kinds  of  unusual  situations  will  not  apply. 
Furthermore,  some  Major  Commands  have  very  detailed  processes  about  how  formalized  entries  are 
made  into  the  system.  One  such  command  estimates  that  it  can  take  upwards  of  more  than  a  year  prior 
to  the  "entry"  as  designated  by  this  model  [151].  Since  every  command  is  different,  the  model  assumes 
the  arrival  of  the  idea  or  program  has  already  finished  going  through  these  other  processes.  The  main 
assumption  is  that  regardless  of  where  a  new  idea  is  generated,  it  must  eventually  follow  this  process 
and  begin  at  this  point.  No  attempt  is  made  to  track  the  original  genesis  of  the  idea,  nor  how  long  it 
takes  for  the  idea  to  make  it  to  the  organization  responsible  for  determining  where  it  needs  to  go. 

The  process  "Set  ACAT  level"  is  simply  a  task  to  randomly  assign  all  entries  to  the  system  to 
different  ACAT  levels.  This  is  an  artificial  exercise  at  this  point.  Normally,  a  great  deal  of  analysis  goes 
into  such  designations.  Unfortunately,  there  are  several  methods  and  ways  that  such  designations  are 
done.  Therefore  to  avoid  having  multiple  "assignment"  modules,  this  was  done  up  front.  Subsequent 
analysis  has  verified  that  this  assignment  up  front  and  early  in  the  process  does  not  impact  the  ratio  of 
ACAT  categories  that  arrive  at  MS  C.  There  is  a  52%  probability  to  be  assigned  an  ACAT  III,  a  14% 
probability  to  be  assigned  an  ACAT  II,  a  5%  probability  to  be  assigned  as  an  ACAT  IAC,  a  9%  probability  to 
be  assigned  as  an  ACAT  1C,  an  8%  probability  to  be  assigned  as  an  ACAT  ID,  and  a  12%  probability  to  be 
assigned  as  an  ACAT  1AM.  The  model  will  lump  all  ACAT  I  variations  together  into  a  general  ACAT  I 
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category.  The  breakout  was  done  to  facilitate  potential  future  work  with  the  model  on  specific  ACAT 
levels. 

The  next  block  in  this  process  flow  is  called  "For  existing  program?"  This  is  a  probabilistic  step 
with  a  75%  probability  that  a  new  idea  will  be  routed  to  an  existing  program  or  organization.  The  source 
of  this  information  is  from  an  interview  conducted  in  2007  and  later  validated  in  2008. 

The  next  process  entitled  "Route  to  proper  organization"  has  a  triangular  distribution.  The 
minimum  is  3  days,  the  most  likely  is  3  days,  and  the  maximum  is  7  days.  The  source  of  this  information 
is  an  interview  with  a  JCIDS  participant  at  the  MAJCOM  level. 

A  probabilistic  decision  point  entitled  "In  scope  of  existing  documents?"  has  a  probability  of  85% 
of  being  in  scope  of  existing  documentation.  The  source  of  this  information  is  derived  from  a  cursory 
review  of  the  number  of  "new  starts,"  e.g.  items  identified  as  "new"  within  the  PPBE  and  also  has  an 
approved  requirement  document,  versus  the  existing  and  approved  budget  line  items.  This 
approximation  was  later  validated  by  interview  data.  If  the  outcome  at  this  step  is  "no"  then  the 
process  proceeds  to  the  next  task,  the  "socializing  waiting  period"  task. 

A  task  entitled  "Prepare  for  acquisition"  has  a  time  distribution  of  5  days  to  1460  days,  or  about 
4  years.  However,  the  distribution  is  skewed  highly  to  the  left,  meaning  that  most  of  the  ideas  do  get 
sent  out  in  a  relatively  short  period  of  time,  so  the  most  likely  value  chosen  was  7  days.  These  data 
points  were  validated  by  a  JCIDS  participant  at  the  MAJCOM.  Some  ideas,  although  they  are  passed  to 
the  proper  organization,  simply  will  never  get  passed  to  acquisition,  which  is  modeled  via  the  large 
upper  bound  to  the  distribution. 

Following  this  task  is  a  decision  point,  titled  "Rejection  outright"  that  rejects  55%  of  these 
projects  or  ideas,  e.g.  the  activity  has  matured  and  is  ready,  or  it  has  not  "bubbled"  up  in  the 
prioritization  processes.  For  the  purposes  of  the  model,  upon  rejection,  this  branch  of  the  model  will 
end  and  is  noted  by  the  "End  Simulation  1"  model  artifact  and  also  artifacts  called  "Record  1"  and  "Early 
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Archive  End"  shown  in  Figure  61.  However,  those  surviving  this  initial  screen  meet  an  "OR"  junction 


where  75%  of  the  process  flow  goes  to  the  next  activity  of  "to  Acquisition  Modernization/Sustainment 
Activity"  while  25%  will  be  sent  to  a  system  currently  in  development. 

Therefore,  the  task  entitled  "to  acquisition  modernization  or  sustainment  activity"  has  a  time 
distribution  of  180  to  1460  days,  with  a  most  likely  value  of  903  days.  The  wide  range  reflects  the 
likelihood  that  the  complexity  of  these  ideas  is  low  (low-cost  modification)  or  development  and 
installation  is  straightforward.  It  also  implies  that  these  ideas  will  tap  into  the  existing  funding  sources 
used  for  sustainment  of  these  programs  and  platforms.  The  most  likely  value  of  903  days  was  derived 
from  a  binomial  distribution  where  p=0.6.  The  source  of  this  information  is  varied:  from  expert  opinion; 
by  inference;  and  discussions  with  various  people  associated  with  these  activities  in  the  acquisition 
community.  It  was  later  validated  by  a  JCIDS  participant. 

For  the  25%  being  sent  to  the  system  currently  in  development,  the  next  step  is  called 
"Determine  the  type  of  requirements  document  needed,"  e.g.  or  the  appropriate  Acquisition  Milestone 
Point  of  entry.  Better  said,  this  step  is  simply  a  waiting  period.  This  waiting  period  is  an  ill-defined 
activity,  but  nonetheless  critical.  It  is  a  time  that  is  used  to  socialize  the  idea  among  the  decision  makers 
within  the  requirements  system  in  an  informal  manner.  It  is  also  a  time  where  the  technology  feasibility 
is  "checked  out",  especially  if  the  source  of  the  new  idea  is  a  contractor.  According  to  interviewees,  the 
current  culture  of  the  requirements  system  is  to  treat  inputs  to  the  process  with  skepticism.  This  is  the 
period  of  time  where  a  notional  ACAT  level  determination  is  made  as  well.  The  time  distribution 
associated  with  this  new  idea  ranges  from  14  days  to  180  days  with  a  most  likely  value  of  118  derived 
from  a  binomial  distribution  where  p  =  .7.  This  information  was  uncovered  during  the  validation  phase 
of  the  model  development  with  the  help  of  a  MAJCOM  JCIDS  participant  and  also  an  acquisition  expert 
within  the  SAF/AQ  organization. 
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Returning  to  another  path,  if  the  determination  of  the  decision  point  "In  scope  of  existing 


documents"  is  no,  the  next  step  is  a  waiting  period.  This  waiting  period  is  an  ill-defined  activity,  but 
nonetheless  critical  for  the  next  step  to  be  taken.  It  is  a  time  that  is  used  to  socialize  the  idea  among  the 
decision  makers  within  the  requirements  system  in  an  informal  manner.  It  is  also  a  time  where  the 
technology  feasibility  is  "checked  out",  especially  if  the  source  of  the  new  idea  is  a  contractor.  The 
culture  of  the  requirements  system  is  to  treat  such  inputs  with  skepticism.  This  is  the  period  of  time 
where  a  notional  ACAT  level  determination  is  made.  The  time  distribution  associated  with  this  new  idea 
ranges  from  14  days  to  180  days  with  a  binomial,  p  =  .7.  This  information  was  uncovered  during  the 
validation  phase  of  this  activity  with  a  JCIDS  participant. 

As  a  point  of  reference,  ICDs  are  pursued  for  two  major  reasons  (if  they  are  forced  to  do  so). 
First,  it  is  used  to  come  up  with  the  best  solution  or  second,  to  justify  a  pre-conceived  notion.  The  good 
news  is  that  the  personnel  who  manage  the  overall  document  process  "never  see  the  same  thing  twice" 
as  an  ICD  and  this  is  based  upon  their  20-plus  years  of  history  working  on  the  overall  process.  This 
observation  was  validated  by  a  JCIDS  participant  supervising  the  process. 

Upon  completion  of  this  step,  the  decision  point  entitled  "decision  to  pursue  requirements"  is 
met.  The  probability  of  proceeding  further  is  25%  simply  because  of  the  burden  required  on  individual 
requirements  officers  to  shepherd  a  new  idea/system/etc  through  the  overall  system.  It  is  a  high 
threshold  and  tends  to  discourage  a  lot  of  frivolous  things  from  entering  into  the  overall  system.  This 
step  was  validated  by  a  JCIDS  participant. 

If  the  answer  is  no,  the  activity  is  considered  out  of  the  scope  of  the  model,  e.g.  actually  stored 
in  an  archive,  and  the  process  flow  ends  at  this  point.  The  items  "End  Simulation  9,"  "Record  35,"  and 
"End  after  waiting  period"  are  model  artifacts  necessary  for  bookkeeping  within  the  model.  The  source 
of  this  information  comes  from  information  obtained  in  interviews,  some  personal  experience  and  by 
inference.  It  was  later  validated  by  a  JCIDS  participant.  In  reality,  at  any  point  in  the  model  where  an 
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idea  or  program  is  "killed"  and  put  into  an  "archive,"  it  simply  means  that  it  can  reenter  the  overall 
system  from  the  beginning  without  official  prejudice  at  another  time. 

Stepping  down  another  branch  earlier  in  the  model,  if  the  decision  point  "For  existing 
Program?"  says  "no,"  a  task  entitled  "Route  to  Advanced  Concepts"  has  a  triangular  time  distribution  of 
3  to  12  days,  with  the  most  likely  result  to  be  7.5  days.  Items  are  routed  here  if  an  existing  program  can 
not  be  determined  to  exist.  The  majority  of  these  ideas  will  be  studied  and  evaluated  by  consultants 
and  others  to  help  this  office  determine  whether  or  not  they  wish  to  proceed  to  the  next  step.  It  is  at 
this  point  that  programs  and  projects  begin  to  receive  their  initial  attribute  characteristics  to  include  the 
concepts'  cost,  schedule,  etc.  This  activity  continues  in  the  next  step  entitled  "waiting  period,"  which  has 
already  been  discussed.  The  source  of  this  information  was  validated  by  a  JCIDS  participant. 

A  task  entitled  "draft  briefing  and  materials"  has  a  time  distribution  of  10  to  40  days,  with  a 
most  likely  value  of  31  days.  The  source  of  this  information  is  from  inference  from  interview  data  with  a 
JCIDS  participant. 

A  decision  point  entitled  "MAJCOM  "A"  letters  Coordinate  and  Concur"  has  a  probability  of  80%. 
The  source  of  this  information  is  interview  and  later  validation  by  a  JCIDS  Participant. 

If  the  decision  of  the  "A"  letters  is  to  proceed,  an  out-of-swim  lane  activity  occurs  in  conjunction 
with  the  Budget  swim  lane  if  it  is  an  ACAT  I  potential  program.  This  will  be  discussed  later  as  it  is 
referenced  on  another  figure.  If  the  decision  of  the  "A"  letters  is  to  decide  against  the  program,  the  next 
step  is  a  decision  point  entitled  "Check  Condition"  checking  to  see  if  the  program  has  "failed"  before.  If 
so,  the  program  is  killed  and  archived,  as  shown  in  the  model  artifacts  "Record  10,"  "End  Simulation  8" 
and  "Archive  for  rejected  ideas  in  formal  review."  If  the  condition  has  only  been  met  once,  the  next  step 
is  setting  a  model  attribute  indicating  it  has  failed,  shown  in  Figure  62,  then  another  decision  point 
debating  whether  or  not  to  pursue  the  process  further,  also  shown  in  Figure  62.  This  decision  point  will 
be  discussed  in  detail  later.  If  "yes,"  the  process  activity  "Update  Briefing  Materials,"  shown  on  Figure 
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60,  is  met.  It  has  a  time  distribution  of  10  to  40  days  with  a  most  likely  value  of  35  days.  The  activity  re¬ 


engages  the  normal  process  at  the  MAJCOM  "A"  letter  stage.  The  source  for  this  information  is  by 
inference,  and  by  discussions  obtained  over  multiple  interviews  with  different  people.  It  was  later 
validated  by  a  JCIDS  participant. 


Following  the  "Acquisition  Modernization  or  Sustainment  Activity,"  a  decision  point  entitled, 
"MDAP  threshold  crossed?"  is  met.  It  has  a  probability  of  10%.  This  particular  decision  point  makes 
sense  at  this  period  of  time,  particularly  if  it  is  a  larger  development.  That's  because  over  time  the 
program  has  reached  a  point  where  certain  acquisition  process  thresholds,  especially  cost  ones,  have 
been  crossed.  As  individuals  working  on  these  programs  become  aware  of  these  thresholds,  they  will  be 
forced  to  make  decisions  and  do  what  is  necessary  to  get  things  back  into  the  formal  process  and  flow  of 
things.  If  the  answer  is  "true"  10%  of  the  time,  the  next  step  is  a  probabilistic  point  where  the  activities 
are  separated  into  the  different  Milestone  tracks.  1%  enter  the  system  as  if  an  ICD  was  just  approved, 
requiring  an  AOA  or  long-term  development,  noted  by  the  model  artifacts  entitled  "Record  36"  and 
"Reinsert  into  Acquisition  Process  A."  24%  enter  the  system  just  prior  to  Milestone  B,  concluding  that 
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no  further  technology  development  is  required.  This  is  noted  by  model  artifacts  "Record  37"  and 
"Reinsert  into  Acquisition  Process  B."  75%  enter  the  system  just  after  Milestone  B  to  begin  system 
development  and  demonstration.  This  is  noted  by  model  artifacts  "Record  38"  and  "Reinsert  into 
Acquisition  Process  C"  (not  shown).  As  stated  with  an  earlier  system  process,  regardless  of  the 
outcome,  there  is  tremendous  institutional  pressure  to  push  the  activity  as  far  forward  in  the  acquisition 
system  as  possible.  These  institutional  pressures  result  from  the  desire  to  field  a  capability  quickly, 
"save"  money  by  avoid  a  long  development  cycle,  and  from  the  belief  that  the  "system"  takes  too  long 
following  the  regular  process.  However,  90%  of  the  time  these  programs  remain  in  the  sustainment 
system.  These  programs  are  then  dropped  from  the  model  for  any  further  processing.  This  is 
represented  by  the  model  artifacts  titled,  "End  Simulation  2,"  "Record  2,"  and  "Continue  until 
completion  and  End  of  process."  The  source  of  this  information  is  derived  from  various  interviews  with 
players  involved  in  the  overall  process  and  was  further  validated  by  a  JCIDS  participant. 

Following  the  process  of  "Determining  type  of  requirements  document  needed"  which  was  also 
shown  on  Figure  60,  the  next  step  is  a  probabilistic  point  where  the  activities  are  separated  into  the 
different  Milestone  tracks.  Five  percent  enter  the  system  as  if  an  ICD  was  just  approved,  requiring  an 
AOA  or  long-term  development.  The  model  artifacts  for  this  are  "Requires  AoA  not  ICD"  and  "Record 
39."  Thirty-five  percent  enter  the  system  just  prior  to  Milestone  B,  concluding  that  no  further 
technology  development  is  required.  These  are  represented  by  the  model  artifacts  "In  Scope  of  existing 
CCD"  and  "Record  40."  Sixty  percent  enter  the  system  just  after  Milestone  B  to  begin  system 
development  and  demonstration.  This  is  also  marked  by  the  model  artifacts  of  "Entry  after  MS  B"  and 
"Record  41"  (shown  in  Figure  62).  Officially,  the  Milestone  Decision  Authority  (MDA)  is  the  one  to 
authorize  entry  into  the  acquisition  system  at  any  point.  Regardless  of  the  outcome,  there  is 
tremendous  institutional  pressure  to  push  the  activity  as  far  forward  or  ahead  in  the  acquisition  system 
as  possible.  These  institutional  pressures  result  from  the  desire  to  field  a  capability  quickly,  "save" 
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money  by  avoiding  a  long  development  cycle,  and  from  the  belief  that  the  "system"  takes  too  long 
following  the  regular  process.  The  aforementioned  percentages  reflect  the  MDA's  deference  to  the 
operator's  desires.  The  source  of  this  information  is  derived  from  various  interviews  with  players 
involved  in  the  overall  process  and  was  further  validated  by  JCIDS  participants. 


Figure  62:  Close  up  of  another  portion  of  the  early  Pre-MS  A  requirement  swim  lane 


Continuing  the  discussion  on  the  decision  of  the  MAJCOM  "A"  letters,  if  the  decision  of  the  "A" 
letters  is  to  proceed,  a  check  is  made  to  determine  the  ACAT  level  of  the  program,  called  "Check  for 
ACAT  level  preA"  in  the  figure  above.  If  it  is  an  ACAT  I  potential  program,  an  out-of-swim  lane  activity 
occurs  in  conjunction  with  the  Budget  swim  lane  (shown  in  Figure  63  and  discussed  later).  If  not,  a  study 
for  the  development  of  the  ICD  is  done,  called  "Study  for  ICD  development."  This  is  known  in  the 
documentation  as  the  Analysis  of  Material  Approaches  and  is  the  last  step  in  an  on-going  process  called 
the  Functional  Solution  Analysis.  This  process  is  not  evaluated  in  detail  in  the  model  and  is  an  example 
of  some  of  the  preliminary  activities  that  are  simultaneously  occurring  outside  of  the  scope  of  the 
model.  For  ACAT  I  type  programs,  the  study  length  is  180  to  360  days,  with  a  most  likely  value  of  300 
days.  For  the  other  ACAT  programs,  these  last  1  to  7  days  with  5  days  being  the  most  likely  value.  The 
funding  for  the  studies  of  non-ACAT  I  programs,  if  required,  comes  out  of  the  organization  sponsoring 
the  document.  The  "7-day"  studies  are  typically  conducted  in-house  by  resident  experts  and  technical 
contractor  support  personnel. 


272 


As  shown  in  Figure  61  and  62,  a  task  entitled  "Update  and  schedule  calendar"  has  a  time 


distribution  of  3  to  15  days,  with  a  most  likely  value  of  12  days.  The  source  of  this  information  is 
inference  derived  from  interview  data. 

A  decision  point  entitled  "Pre-RSR  MAJCOM  A8"  has  a  probability  of  95%.  The  probability 
changes  to  99%  if  this  idea  has  been  through  the  system  before.  The  source  of  this  information  is  an 
interview. 

A  task  entitled  "finalize  RSR  and  calendar  items"  in  Figure  61  has  a  time  distribution  of  21  to  35 
days,  with  a  most  likely  value  of  28  days.  The  source  of  this  information  is  from  an  interview  and  was 
later  validated  by  a  JCIDS  participant  and  the  official  Document  Timeline  Calculator  [152], 

A  decision  point  entitled  "RSR  Mr.  Harry  Disbrow  HQ  USAF  A5R,"  Figure  61,  has  a  probability  of 
98%.  The  source  of  this  information  is  an  interview.  If  the  answer  to  this  decision  point  is  "no",  the 
process  returns  to  the  originator  and  another  decision  point  is  reached,  entitled  "Check  value"  in  Figure 
60. 

The  RSR  must  include  the  funding  strategy  for  the  pre-A  and  pre-B  (Concept  Refinement  and 
Technology  Development)  phases.  Note  that  it  does  not  include  a  guarantee  of  funds  -  rather  it  is  a 
strategy  or  best  guess  or  promise  to  fund.  This  step  is  also  when  a  program  is  given  its  Joint  Potential 
Designator.  ACAT  I  activities  have  a  100%  chance  of  getting  joint  interest.  ACAT  II  activities  are  usually 
designated  as  "joint  information"  and  any  comments  are  taken  under  advisement,  while  ACAT  III 
activities  are  designated  "independent"  AF  only  and  are  distributed  to  the  other  services  as  a  courtesy 
only  for  comment  and  review.  The  joint  information  was  validated  by  an  interviewee  in  A35  and  the 
official  Document  Timeline  Calculator. 

Assuming  this  was  a  first  time  rejection  by  the  RSR  and  clearing  the  model  artifact  checking  for  a 
failure  flag,  it  then  meets  the  model  artifact  entitled  "Add  counter  through  feedback  path,"  which  was 
discussed  earlier.  The  probability  of  the  decision  point  "decision  to  pursue"  is  approximately  85%.  If 
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successful,  the  next  step  is  back  to  the  MAJCOM  "A"  letters.  If  not,  the  item  is  killed  and  archived,  with 


the  model  artifacts  "Record  9,"  "End  Simulation  8,"  and  "Archive  for  rejected  ideas  in  formal  review",  all 
discussed  earlier  and  shown  in  Figure  60. 

Returning  to  the  process  flow  upon  approval  by  the  RSR,  the  next  task  is  called  "form  high 
performance  team"  has  a  time  distribution  of  approximately  30  to  45  days,  with  a  most  likely  value  of  41 
days.  The  source  of  this  information  is  an  interview  and  validated  by  a  JCIDS  participant  and  the  official 


Figure  63:  Pre-MS  A  early  PPBE  activity 


If  after  the  MAJCOM  "A-letter"  decision  and  the  program  is  designated  ACAT  I,  a  decision  point 
entitled  "Request  for  funds  between  August  and  December?"  is  met.  In  some  sense,  this  is  an  artificial 
necessity  of  the  model  to  account  for  the  limited  resources  that  exist  for  concept  development  and  to 
demonstrate  the  effects  of  timing  upon  certain  development  activities.  In  reality,  this  "check  for  funds" 
occurs  simultaneously  during  the  development  of  an  idea  prior  to  the  "A-letter"  decision.  They  can  still 
approve  the  activity  contingent  upon  the  availability  of  funds.  The  probability  of  answering  affirmative 
to  this  query  is  70%.  If  not,  the  task,  "wait  until  next  year"  does  just  that,  with  a  time  distribution  of  180 
to  270  days,  with  250  days  as  the  most  likely  value.  This  distribution  allows  for  fall-out  moneys  to 
jumpstart  a  program.  The  source  of  this  information  is  by  inference  and  has  been  validated  by  a  JCIDS 
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participant.  Since  funding  for  an  entirely  new  idea  will  come  out  of  the  yearly  appropriated  yet  un- 
definitized 60  budget  for  "Advanced  Concepts"  there  is  likely  some  informal  coordination  occurring  prior 
to  the  initiation  of  these  out  of  swim-lane  steps.  There  will  be  some  sort  of  ranking  criteria,  either  via 
analysis  or  FIFO,  etc.,  to  fund  these  requests.  Therefore,  if  the  answer  is  "no",  the  process  task  moves  to 
the  bottom  of  the  "list"  and  "waits  until  next  year." 


The  task  called  "High-Performance  Team  (HPT)  work"  in  Figure  64  has  a  time  distribution  of  5  to 
7  days,  with  a  most  likely  value  of  6  days.  The  source  of  this  information  is  an  interview  with  a  JDICS 
participant.  The  product  of  this  event  is  a  "draft  document".  Since  members  of  the  Acquisition  swim 
lane  are  part  of  the  HPT,  this  serves  as  the  informal  trigger  for  advance  Acquisition  activities  to  occur  as 
described  later  in  this  document.  This  is  not  explicitly  modeled  here.  At  this  point,  a  decision  point 
entitled  "Determine  document  approval  path  preA"  separates  the  activity  into  three  separate  paths  to 
approval  depending  upon  the  Joint  Potential  Designator,  e.g.  a  "rough"  surrogate  for  the  ACAT  level,  of 
the  activity.  The  model  separates  these  based  on  the  previously  designated  ACAT  level.  ACAT  I 
programs  go  to  the  "Joint  Interest  preA"  step.  ACAT  II  programs  go  to  the  "Joint  Integration  preA"  step 
and  ACAT  III  programs  go  to  the  "Independent  Document  preA"  step.  More  detail  is  given  in  the  table 
below. 

60  Undefinitized  -  refers  to  a  budget  where  the  specific  spending  items  and  priorities  have  not  yet  been 
established. 
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Joint 

Staff 

Approval 


AF 
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Table  52:  Approval  Authority  level  for  JCIDS  documents  based  on  ACAT  level 

Following  the  completion  of  these  steps,  which  will  be  discussed  in  detail  shortly,  the  ICD 
completion  time  is  recorded  as  an  artifact  of  the  model  with  the  step,  "Record  ICD  time,"  and  a  check 
point  for  ACAT  level  is  met  by  the  programs.  ACAT  II  or  III  programs  proceed  to  a  PPBE  activity,  while 
ACAT  I  programs  begin  the  process  titled,  "Develop  AoA  Plan  ACAT  I."  This  activity  has  a  process 
duration  of  60  to  90  days  with  a  most  likely  value  of  75  days.  This  step  was  validated  by  official 
documentation  and  JCIDS  participants. 


Figure  65:  Pre  MS-A  Independent  document  process 

The  task  called  "Draft  document  Indep  preA"  has  a  time  distribution  of  30  to  60  days,  with  a 
most  likely  value  of  55  days  and  is  really  an  "advanced"  draft  of  the  document  previously  worked  on  by 
the  High  Performance  team.  This  is  the  time  for  internal  coordination  and  clean-up.  The  source  of  this 
information  is  an  interview  and  validated  by  JCIDS  participants  as  well  as  by  the  official  Document 
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Timeline  Calculator.  In  reality,  at  this  point,  information  is  passed  to  the  acquisition  system  for 
preparatory  work. 

The  task  called  "air  staff  processes"  has  a  time  distribution  of  21  to  42  days,  with  a  most  likely 
value  of  29  days.  The  source  of  this  information  is  interview  and  official  documentation.  A  few  days  of 
internal  processing  time  and  a  maximum  21-day  review  (with  the  possibility  of  an  extension)  form  the 
basis  of  the  time  distribution.  The  information  was  later  validated  by  a  JCIDS  participant  and  the  official 
Document  Timeline  Calculator. 

The  decision  point  entitled  "Critical  comments  Indep  PreA?"  has  a  probability  of  95%.  The 
source  of  this  information  is  an  interview  and  validated  by  JCIDS  participant.  If  there  are  no  critical 
comments,  the  task  proceeds  to  the  AFROC  Preparations  step. 

The  task  called  "comment  resolution  indep  preA"  has  a  time  distribution  of  15  to  45  days,  with  a 
most  likely  value  of  45  days.  This  is  where  the  sponsor  resolves  0-661  level  comments.  The  source  of 
this  information  is  interview  and  validation  by  JCID  participant  and  the  official  Document  Timeline 
Calculator. 

The  decision  point  entitled  "MAJCOM  approval  indep  preA?"  has  a  probability  of  99%.  The 
source  of  this  information  is  interview  and  later  validation  by  JCIDS  participant.  If  the  answer  is  no,  the 
next  step  remains  comment  resolution  and  information  is  passed  into  the  budgeting  and  programming 
system  to  deal  with  the  financial  ramifications.  Usually,  this  means  the  activity  is  put  on  "hold"  for  a 
year,  probably  the  result  of  some  "critical  comments"  that  were  not  immediately  resolved.  This  is 
represented  by  the  step,  "Hold  for  a  year  later  in  process  Indep  preA."  It  has  a  time  distribution  of  270 
to  365  days,  with  a  most  likely  value  of  300  days.  If  the  answer  is  yes,  the  activity  proceeds  to  the  next 
step. 


0-6:  refers  to  a  Colonel  or  Captain  (for  the  Navy). 
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The  task  called  "AFROC  preparations  Indep  preA"  has  a  time  distribution  of  30  to  60  days,  with  a 


most  likely  value  of  45  days.  The  source  of  this  information  is  an  interview  and  the  official  Document 
Timeline  Calculator. 

The  decision  point  "AFROC  decision  indep  preA"  has  a  probability  of  90%.  Of  those  90%,  20%  to 
30%  will  have  "actions"  (Post  AFROC  "Go-do"  actions)  to  accomplish,  see  step  "Post  AFROC  actions 
Indep  preA"  and  must  return  to  the  AFROC  within  0  to  15  days,  with  a  most  likely  value  of  11  days.  The 
source  is  the  official  Document  Timeline  Calculator. 

If  the  initial  answer  at  the  AFROC  is  "no,"  there  is  a  99%  chance  the  activity  is  "dead"  and  the 
document  is  archived.  First,  there  is  a  check  to  see  if  the  rejection  is  the  first  time  or  not.  This  is  done  at 
the  step  entitled,  "Check  for  previous  path  indep  PreA."  The  model  sets  a  variable  in  "Set  tracking  Indep 
PreA."  The  next  step  is  "Dead  activity  Indep  PreA."  This  step  has  a  probability  of  99%  being  killed.  If 
not,  the  program  goes  back  to  the  step  "comment  resolution  Indep  PreA."  During  validation,  the  source 
indicated  he  had  never  seen  anything  go  back  through  the  AFROC  a  2nd  time  based  on  his  25+  years  of 
experience.  Therefore,  the  path  taken  by  the  less  than  likely  1%  of  documents  would  be  back  to  the 
MAJCOM  for  approval  through  the  comment  resolution  process  and  follow  the  normal  process  beyond 
that.  Otherwise,  the  activity  is  "dead"  and  this  is  represented  by  the  model  artifacts  "End  Simulation 
PreA  1,"  "Record  20,"  and  "Death  at  AFROC  Indep  PreA."  The  source  of  this  information  is  an  interview 
as  well  as  review  of  official  process  documents.  It  has  been  validated  by  a  JCIDS  participant. 

At  this  point  the  ICD  is  approved  and  resumes  the  normal  flow  in  the  combined  process,  as 
depicted  in  Figure  64. 
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Figure  66:  Pre-MS  A  Joint  Integration  document  process,  part  I 

The  task  called  "draft  document  joint  integ  preA"  has  a  time  distribution  of  30  to  60  days,  with  a 
most  likely  value  of  55  days.  This  is  really  an  "advanced"  draft  of  the  document  previously  worked  on  by 
the  High  Performance  team.  It  is  the  time  for  internal  coordination  and  clean-up.  The  source  of  this 
information  is  an  interview  and  validated  by  JCIDS  participant  as  well  as  by  the  official  Document 
Timeline  Calculator.  In  reality,  information  is  passed  to  the  acquisition  system  for  preparatory  work. 

The  task  called  "air  staff  processes  joint  integ  preA"  has  a  time  distribution  of  21  to  42  days  with 
a  most  likely  value  of  29  days.  The  source  of  this  information  is  interview  and  official  documentation.  A 
few  days  of  internal  processing  time  and  a  maximum  21-day  review  (with  the  possibility  of  an  extension) 
form  the  basis  of  the  time  distribution.  The  source  of  this  information  was  validated  by  JCIDS  participant 
and  the  official  Document  Timeline  Calculator. 

The  decision  point  entitled  "Critical  comments  joint  integ  preA"  has  a  probability  of  95%.  The 
source  of  this  information  is  an  interview  and  validated  by  JCIDS  participant.  If  there  are  no  critical 
comments,  the  task  proceeds  to  the  "Document  review  phase  joint  integ  preA." 

The  task  called  "comment  resolution  joint  integ  preA"  has  a  time  distribution  of  15  to  45  days, 
with  a  most  likely  value  of  30  days.  This  is  where  the  sponsor  resolves  0-6  level  comments.  The  source 
of  this  information  is  interview  and  validation  by  JCIDS  participant  and  the  official  Document  Timeline 
Calculator. 
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The  decision  point  entitled  "MAJCOM  approval  joint  integ  preA?"  has  a  probability  of  99%.  The 


source  of  this  information  is  interview  and  later  validation  by  JCIDS  participant.  If  the  answer  is  no,  the 
next  step  remains  comment  resolution  and  information  is  passed  into  the  budgeting  and  programming 
system  to  deal  with  the  financial  ramifications.  Usually,  this  means  the  activity  is  put  on  "hold"  for  a 
year,  probably  the  result  of  some  "critical  comments"  that  were  not  immediately  resolved.  This  step  is 
entitled  "Hold  for  a  year  later  in  process  joint  integ  preA"  with  a  time  distribution  of  270  to  365  days, 
with  a  most  likely  value  of  300  days.  If  the  answer  is  yes,  the  activity  proceeds  to  the  next  step. 

The  step  "Document  review  phase  joint  integ  preA"  is  applicable  to  50%  of  the  documents 
seeking  approval.  The  other  50%  proceed  directly  to  the  Interoperability  Certification  step.  The  next 
step,  for  those  that  require  it,  is  called  the  "Document  Review  Phase  2  Flag  level  joint  integ  preA".  This 
activity  is  taking  place  because  there  were  "critical  comments"  that  were  not  resolved  during  the  initial 
round  and  the  MAJCOM  sponsor  determined  to  press  ahead  anyway.  This  step  has  a  time  distribution 
of  21  to  42  days,  with  a  most  likely  value  of  34  days.  This  has  been  validated  by  the  Official  Document 
Timeline  Calculator. 

The  next  step  is  another  round  of  the  sponsor  "Resolving  Flag  Level  Comments  joint  integ  preA." 
The  time  distribution  is  15  to  30  days,  with  a  most  likely  value  of  28  days.  This  was  validated  by  the 
official  Document  Timeline  Calculator. 

The  decision  point  entitled  "MAJCOM  approval  joint  integ  preA"  has  a  probability  of  99%.  The 
source  of  this  information  is  interview  and  later  validation  by  JCIDS  participant.  If  the  answer  is  no,  the 
next  step  remains  comment  resolution  and  information  is  passed  into  the  budgeting  and  programming 
system  to  deal  with  the  financial  ramifications.  Usually,  this  means  the  activity  is  put  on  "hold"  for  a 
year,  probably  the  result  of  some  "critical  comments"  that  were  not  immediately  resolved.  This  step  is 
titled  "Hold  for  a  year  later  in  process  2nd  time  joint  integ  preA."  This  step  has  a  time  distribution  of  270 
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to  300  days,  with  a  most  likely  value  of  300  days.  If  the  answer  is  yes,  the  activity  proceeds  to  the  next 


step.  This  step  was  validated  by  the  official  Document  Timeline  Calculator. 

The  step  called  "Interoperability  Certification  joint  integ  preA"  has  a  time  distribution  of  10  to  20 
days,  with  a  most  likely  value  of  15  days.  The  validation  came  from  the  official  Document  Timeline 
Calculator. 


Figure  67:  Pre-MS  A  Joint  Integration  document  process,  part  II 

The  task  called  "AFROC  preparations  joint  integ  preA"  has  a  time  distribution  of  30  to  60  days, 
with  a  most  likely  value  of  45  days.  The  source  of  this  information  is  an  interview  and  the  official 
Document  Timeline  Calculator. 

The  decision  point  "AFROC  decision  joint  integ"  has  a  probability  of  90%.  Of  those  90%,  20%  to 
30%  will  have  "actions"  (Post  AFROC  "Go-do"  actions)  to  accomplish.  This  possibility  is  called  "Post 
AFROC  actions  joint  integ  preA."  The  step  "Accomplish  Post  AFROC  actions  joint  integ  preA"  includes 
returning  to  the  AFROC  within  0  to  15  days,  with  a  most  likely  value  of  11  days.  If  the  initial  answer  at 
the  AFROC  decision  is  "no,"  there  is  a  99%  chance  the  activity  is  "dead"  and  the  document  is  archived. 
During  validation  of  the  model,  the  source  indicated  he  had  never  seen  anything  go  back  through  the 
AFROC  a  2nd  time  based  on  his  25+  years  of  experience.  The  path  taken  by  the  less  than  likely  1%  of 
documents  would  be  back  to  the  MAJCOM  for  approval  through  the  comment  resolution  process  and 
follow  the  normal  process  beyond  that.  For  the  logic  of  the  model  to  remain  intact,  the  program  is  first 
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checked  to  see  if  it  has  previously  been  rejected.  If  not,  a  variable  is  set.  Then  it  meets  the  step  "Dead 


activity  joint  integ  preA"  with  a  99%  probability  of  being  killed  outright.  If  not,  it  is  then  set  back  to  the 
comment  resolution  step.  Otherwise,  the  program  is  killed  via  the  model  artifacts  "End  Simulation  Joint 
Int  preA  1,"  "Record  19,"  and  "Death  at  AFROC  joint  integ  preA."  The  source  of  this  information  is  an 
interview,  the  official  Document  Timeline  Calculator  as  well  as  review  of  official  process  documents.  It 
has  been  validated  by  JCIDS  participant. 

The  step  "Document  signing  and  validation  joint  integ  preA"  is  because  the  AFROC  then  requires 
14  to  30  days,  with  a  most  likely  value  of  26  days,  to  get  the  document  signed  and  validated  across  the 
AF  structure.  The  step  "Final  AFROC  approval  joint  integ  preA"  has  a  99%  chance  to  be  approved  by  the 
AFROC  without  issues.  The  remaining  1%  have  issues  requiring  resolution,  e.g.  step  "Final  AFROC 
resolution  joint  integ  preA,"  typically  requiring  42  to  60  days  to  resolve,  with  a  most  likely  value  of  48 
days. 


Figure  68:  Pre-MS  A  Joint  Interest  document  process,  part  I 


The  task  called  "draft  document  preA  joint  interest"  has  a  time  distribution  of  30  to  60  days, 
with  a  most  likely  value  of  55  days.  It  is  really  an  "advanced"  draft  of  the  document  previously  worked 
on  by  the  High  Performance  team.  This  is  the  time  for  internal  coordination  and  clean-up.  The  source  of 
this  information  is  an  interview  and  validated  by  JCIDS  participant  as  well  as  by  the  official  Document 
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Timeline  Calculator.  Information  is  also  passed  to  the  acquisition  system  for  preparatory  work,  but  is 


not  done  explicitly  in  this  model. 

The  task  called  "air  staff  processes  joint  int  preA"  has  a  time  distribution  of  21  to  42  days,  with  a 
most  likely  value  of  25  days.  The  source  of  this  information  is  interview  and  official  documentation.  A 
few  days  of  internal  processing  time  and  a  maximum  21-day  review,  with  the  possibility  of  an  extension, 
form  the  basis  of  the  time  distribution.  The  source  of  this  information  was  validated  by  JCIDS  participant 
and  the  official  Document  Timeline  Calculator. 

The  decision  point  entitled  "critical  comments?  Joint  int  preA"  has  a  probability  of  95%.  The 
source  of  this  information  is  an  interview  and  validated  by  JCIDS  participant.  If  there  are  no  critical 
comments,  the  task  proceeds  to  the  AFROC  Preparations  step. 

The  task  called  "Comment  resolution  joint  int  preA"  has  a  time  distribution  of  15  to  45  days, 
with  a  most  likely  value  of  30  days.  This  is  where  the  sponsor  resolves  0-6  level  comments.  The  source 
of  this  information  is  interview  and  validation  by  JCIDS  participant  and  the  official  Document  Timeline 
Calculator. 

The  decision  point  entitled  "MAJCOM  approval?  Joint  int  preA"  has  a  probability  of  99%.  The 
source  of  this  information  is  interview  and  later  validation  by  JCIDS  participant.  If  the  answer  is  "no," 
the  next  step  remains  comment  resolution  and  information  is  passed  into  the  budgeting  and 
programming  system  to  deal  with  the  financial  ramifications.  Usually,  this  means  the  activity  is  put  on 
"hold"  for  a  year,  probably  the  result  of  some  "critical  comments"  that  were  not  immediately  resolved. 
This  is  represented  by  the  step  "hold  for  a  year"  with  a  time  distribution  of  270  to  365  days,  with  a  most 
likely  value  of  300  days.  If  the  answer  is  yes,  the  activity  proceeds  to  the  next  step. 

The  task  called  "AFROC  preparations  joint  int  preA"  has  a  time  distribution  of  30  to  60  days,  with 
a  most  likely  value  of  45  days.  The  source  of  this  information  is  an  interview  and  the  official  Document 
Timeline  Calculator. 
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The  decision  point  "AFROC  decision  joint  int  preA"  has  a  probability  of  90%.  Of  those  90%,  20% 


to  30%  will  have  "actions"  (Post  AFROC  "Go-do"  actions)  to  accomplish.  This  is  represented  by  "Post 
AFROC  actions  joint  int  preA."  Those  programs  with  actions  to  accomplish,  e.g.  "Post  AFROC  actions" 
must  return  to  the  AFROC.  It  has  a  time  distribution  of  0  to  15  days,  with  a  most  likely  value  of  11  days. 
If  the  initial  answer  is  "no,"  there  is  a  99%  chance  the  activity  is  "dead"  and  the  document  is  archived. 
During  validation,  the  source  indicated  he  had  never  seen  anything  go  back  through  the  AFROC  a  2nd 
time  based  on  his  25+  years  of  experience.  This  is  represented  by  first  checking  to  see  if  the  program 
had  been  rejected  at  the  AFROC  before.  If  not,  a  flag  was  set,  e.g.  "Set  tracking  point  int  preA."  Then 
the  decision  point,  "Dead  Activity  joint  int  preA"  has  a  99%  probability  that  the  program  would  be  killed 
anyway.  The  path  taken  by  the  less  than  likely  1%  of  documents  would  be  back  to  the  MAJCOM  for 
approval  through  the  comment  resolution  process  and  follow  the  normal  process  beyond  that.  The 
source  of  this  information  is  an  interview  as  well  as  review  of  official  process  documents.  It  has  been 
validated  byJCIDS  participant. 

The  next  step  is  applicable  to  50%  of  the  documents  seeking  approval.  The  other  50%  proceed 
directly  to  the  Functional  Capabilities  Board.  This  is  called  the  "Document  Review  Phase  2  Flag  level." 
This  activity  is  taking  place  because  there  were  "critical  comments"  that  were  not  resolved  during  the 
initial  round  and  the  MAJCOM  sponsor  determined  to  press  ahead  anyway.  This  step  has  a  time 
distribution  of  21  to  42  days,  with  a  most  likely  value  of  38  days.  This  has  been  validated  by  the  Official 
Document  Timeline  Calculator. 


Figure  69:  Pre-MS  A  Joint  Interest  document  process,  part  II 
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The  next  step  is  another  round  of  the  sponsor  "Resolving  Flag  Level  Comments."  The  time 


distribution  is  15  to  30  days,  with  a  most  likely  value  of  27  days.  This  was  validated  by  the  official 
Document  Timeline  Calculator. 

The  decision  point  entitled  "MAJCOM,  approval?"  has  a  probability  of  99%.  The  source  of  this 
information  is  interview  and  later  validation  by  JCIDS  participant.  If  the  answer  is  no,  the  next  step 
remains  comment  resolution  and  information  is  passed  into  the  budgeting  and  programming  system  to 
deal  with  the  financial  ramifications.  Usually,  this  means  the  activity  is  put  on  "hold"  for  a  year, 
probably  the  result  of  some  "critical  comments"  that  were  not  immediately  resolved.  This  step  is  called 
"Hold  for  a  year  later  in  process"  with  a  time  distribution  of  270  to  365  days,  with  a  most  likely  value  of 
300  days.  If  the  answer  is  yes,  the  activity  proceeds  to  the  next  step. 

Next  is  the  "Functional  Capabilities  Board"  for  preparation  and  validation.  This  step  has  a  time 
distribution  of  7  to  21  days,  with  a  most  likely  value  of  14  days.  This  is  considered  a  very  difficult 
"scrub"  of  the  activity.  The  model  is  programmed  to  assume  all  documents  proceed  without  problem  to 
the  next  step62.  This  step  was  validated  by  JCIDS  participant,  A5  participant,  and  the  official  Document 
Timeline  Calculator. 

The  Joint  Capabilities  Board  requires  another  7  to  21  days  in  preparation  after  the  FCB,  with  a 
most  likely  value  of  14  days.  Following  this  is  logic,  titled  "JCB  issues,"  where  85%  that  meet  the  JCB 
board  go  on  to  the  next  step.  The  remaining  15%  have  issues  to  resolve,  titled  "Resolve  JCB  issues," 
typically  taking  10  to  20  days,  with  a  most  likely  value  of  15  days,  before  reporting  back  to  the  JCB. 


Unfortunately,  this  is  not  the  case.  This  error  was  discovered  while  preparing  this  dissertation  for  publication. 
The  actual  data  is  that  70%  that  meet  the  board  go  on  to  the  next  step.  The  other  30%  have  issues  to  resolve, 
typically  taking  10  to  20  days,  with  the  most  likely  value  of  15  days  before  reporting  back  to  the  FCB.  However,  the 
likelihood  of  another  set  of  issues  arising  is  so  remote  that  it  is  assumed  to  have  a  probability  of  zero.  Given  that 
the  magnitude  of  this  error  is  on  the  order  of  a  handful  of  days  versus  the  end  result  on  the  order  of  thousands  of 
days,  it  is  judged  that  the  overall  results  in  the  dissertation  are  still  valid. 
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However,  the  likelihood  of  another  set  of  issues  arising  at  the  second  meeting  of  the  JCB  is  so  remote 
that  the  model  does  not  consider  it  at  all. 

The  JROC  requires  14  to  30  days,  with  a  most  likely  value  of  25  days,  in  preparations,  e.g.  mostly 
calendar  scheduling  issues,  as  noted  in  the  step  titled,  “JROC  Preparations."  At  the  decision  point 
"JROC,"  98%  are  approved  without  issues.  The  remaining  2%  have  issues  requiring  resolution,  typically 
requiring  42  to  60  days  to  resolve,  with  a  most  likely  value  of  51  days,  as  shown  in  the  process  step 
"Resolve  JROC  issues." 

At  this  point  the  ICD  is  approved  and  the  program  resumes  the  process  flow  as  depicted  in 
Figure  64. 


Figure  70:  Pre-MS  A  PPBE  and  early  Acquisition  activities 


Following  the  RSR,  the  Requirements  process  must  determine  if  it  wants  to  proceed  further  in 
developing  the  concept.  A  "waiting  period  for  moneys  to  become  properly  aligned"  is  encountered  at 
this  point.  It  requires  an  out-of-swim  lane  activity  in  conjunction  with  the  Budget  swim  lane.  In  reality, 
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this  "check  for  funds"  occurs  simultaneously  during  the  build-up  to  the  approval  of  the  ICD.  The 
probability  of  answering  affirmative  to  this  query  is  70%  for  ACAT  I  designations,  titled  "ACAT  I  funding." 
For  ACAT  II  or  III,  titled  "ACAT  II  or  ACAT  III  funding,"  the  availability  is  99%.  Much  of  this  difference  is 
based  on  the  approach  of  the  sponsoring  command.  Money  for  studies  is  highly  dependent  upon  the 
overall  cost  and  scope  of  the  activity.  For  an  ACAT  II  or  III,  the  cost  of  an  Analysis  of  Alternatives  may  be 
greater  than  the  cost  of  the  whole  activity.  This  boils  down  to  a  judgment  call  on  the  part  of  the 
sponsoring  organization  and  is  captured  in  the  percentages  cited.  If  the  "check  for  funds"  is  not 
successful,  the  task,  "Wait  for  a  year"  does  just  that,  with  a  time  distribution  of  180  to  270  days,  with  a 
most  likely  value  of  250  days.  This  range  allows  for  fall-out  moneys  to  be  obtained  earlier  than  a  year  to 
jumpstart  a  program.  Furthermore,  these  percentages  are  due  to  the  fact  that  an  Analysis  of 
Alternatives  is  required  for  anything  that  is  an  ACAT  I.  ACAT  II  or  ACAT  III  activities  are  only  required  if 
the  Milestone  Decision  Authority  "directs  one"  to  be  done.  The  source  of  this  information  is  by 
inference  and  validation. 

The  same  time  the  "check  for  funds"  is  taking  place,  another  activity  is  done  simultaneously, 
although  the  model  shows  this  task  being  done  serially.  This  is  an  out  of  swim-lane  activity  where  the 
MDA  examines  the  approved  ICD  and  determines  the  criteria  for  the  AOAs  for  ACAT  I  programs  and  1% 
of  ACAT  II  and  ACAT  III  activities.  The  model  takes  the  1%  of  ACAT  II  and  ACAT  III  programs  that  do  not 
have  sufficient  funds  and  are  placed  on  the  "wait  a  year"  path  and  sets  a  flag  to  do  the  AOA.  This  is  a 
reasonable  assumption  as  AOAs  tend  to  be  expensive  and  would  like  not  have  sufficient  funds  to 
conduct  a  full-blown  AOA  without  seeking  additional  moneys.  Normally,  this  decision  would  come  out 
of  the  Acquisition  Panel  activities  that  are  happening  in  parallel  to  the  events  in  the  Requirements  swim 
lane. 

Next,  the  programs  are  split  between  ACAT  I  and  all  other  ACAT  levels,  e.g.  see  "ACAT  level 
check  for  Acquisition  swim  lane  preA,"  to  make  preparations  for  the  Acquisition  panels.  The  task  "ACAT 
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I  prepare  for  Acquisition  panels"  has  a  time  distribution  of  40  to  60  days,  with  a  most  likely  value  of  55 


days.  This  was  validated  by  A35. 

Upon  completion  of  this  process,  a  process  called  "Acquisition  Panels"  has  a  time  distribution  of 
15  to  35  days,  with  a  most  likely  value  of  30  days.  The  source  for  this  information  comes  from 
interviews  and  published  timelines  and  documents. 

Next,  the  decision  point,  "Concept  Decision  and  ADM,"  is  met.  It  has  a  99%  probability  of 
approval.  If  "yes",  an  Acquisition  Decision  Memorandum  is  issued.  The  ADM  "officially  starts  the 
acquisition  process  and  documents  the  results  of  the  Concept  Decision"  per  AFI  63-101.  The  concept 
decision  contains  "descriptions  of  the  responsibilities  of  each  organization,  the  funding  source,  and  the 
actions  necessary  to  prepare  for  Milestone  A"  per  AFI  63-101,  pg  41.  The  MDA  examines  the  approved 
ICD  and  sets  and  outlines  criteria  for  the  AOAs  for  ACAT  I  programs  and  1%  of  ACAT  II  and  ACAT  III 
activities,  as  described  earlier.  If  the  concept  decision  is  refused,  a  check  is  made  to  see  if  it  had  been 
denied  before.  If  so,  the  program  is  ended  and  recorded  via  the  model  artifacts  of  "End  Simulation  7," 
"Record  6,"  and  "Kill  by  MDA  at  Concept  Decision"  (not  shown  above).  If  not,  a  flag  is  set  to  indicate  the 
failure  of  the  program  at  the  concept  decision  and  it  goes  back  into  the  acquisition  panel  process  for 
another  attempt. 
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Figure  71:  Pre-MS  A  AOA  activities 


Upon  favorable  completion  of  the  Concept  Decision  step,  the  model  checks  to  see  if  an  AOA  is 
required,  e.g.  "Check  for  AOA."  If  the  program  is  an  ACAT  I,  it  has  already  completed  the  step.  If  a  flag 
was  attached  to  an  ACAT  II  or  III  program,  it  must  complete  the  step,  "Develop  AOA  plan,"  which  has  a 
time  distribution  of  60  to  90  days,  with  a  most  likely  value  of  75  days.  For  purposes  of  simplicity,  the 
entire  planning  process  and  approvals  required  for  the  AOA  activity,  including  a  visit  to  the  AFROC  for 
validation)  have  been  combined  into  this  activity.  The  shortened  length  acknowledges  that  much  of  the 
work  required  builds  upon  the  ICD  and  other  studies  as  well  as  much  of  this  being  done  in  parallel  with 
the  ICD  development  and  approval  process. 

At  this  point,  during  the  execution  of  the  AOA  or  the  mini-study,  the  model  requires  the  flow  to 
be  split  in  order  to  allow  parallel  processing  of  activities.  This  occurs  at  the  "Trigger  Acquisition  swim 
lane  activity"  and  at  the  "Non  AOA  Route"  splitting  functions.  One  flow  remains  in  the  requirements 
swim  lane  and  the  other  flow  proceeds  to  the  acquisition  swim  lane.  This  is  a  necessary  artifact  of  the 
model  required  for  correct  operation. 
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For  non-AOA  programs,  an  "Analysis"  step  or  mini-study  is  completed.  This  step  has  a  time 


distribution  of  2  to  180  days,  with  a  most  likely  value  of  7  days.  This  information  came  out  during  the 
validation  process,  when  it  was  described  that  most  analysis  activities  were  done  on  the  "back  of  an 
envelope"  for  most  programs.  From  AFI10-601,  the  statement  is  "The  analytic  effort  should  be 
commensurate  with  the  overall  program  cost." 

The  decision  point  "conduct  AOA"  has  a  probability  of  99%  at  this  point.  The  1%  other  outcome 
reflects  an  end  to  the  process  because,  in  reality,  the  activity  will  be  restructured  differently,  e.g.  to  be 
less  expensive,  less  ambitious,  etc.,  and  will  go  through  the  entire  process  again.  This  outcome  is 
reflected  in  the  model  artifacts  "Set  AOA  kill  flag,"  "End  Simulation  4,"  "Record  4,"  and  "End  at  AOA 
check."  This  decision  point  is  also  an  artifact  of  the  model  to  account  for  real-world  contingencies  that 
may  cause  money  to  be  expected  or  promised  but  not  arriving.  The  source  of  this  information  is  based 
on  interviews.  Since  the  funding  comes  out  of  the  yearly  appropriated  yet  vaguely  definitized  budget  for 
"Advanced  Concepts"  and  since  this  office  is  close  to  the  requirements  organization,  there  is  likely  some 
informal  coordination  occurring  prior  to  the  initiation  of  the  overall  process.  This  was  discussed  prior  in 
the  PPBE  elements  in  Figure  70.  There  is  some  kind  of  ranking  criteria,  e.g.  either  via  analysis  or  FIFO, 
etc.,  to  fund  these  requests. 

If  the  answer  to  conduct  the  AOA  is  "yes",  after  a  time  check  is  conducted,  the  task  "Analysis  of 
Alternatives"  is  met.  The  time  distribution  for  the  AOA  is  270  days  to  730  days,  with  a  most  likely  value 
of  600  days.  The  AOA  will  determine  performance,  schedule,  and  cost  expectations  for  the  program. 
Afterwhich,  another  time  check  is  performed  to  determine  the  actual  AOA  duration,  as  an  artifact  of  the 
model.  This  information  has  been  validated  by  JCIDS  participant. 
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Figure  72:  Pre-MS  A  Acquisition  activities  parallel  to  AOA 


From  the  split  off  of  the  AOA  activities,  the  ACAT  I  split  goes  to  a  queue  entitled,  "Wait  for  AOA 
start."  When  the  AOA  is  started,  the  program  is  released  from  the  queue.  This  is  an  artifact  of  the 
model  required  to  mimic  real-world  behavior.  All  of  the  ACAT  programs  that  were  split  off  of  the  AOA 
activities  enter  the  "Continue  with  other  Acquisition  Swim  lane  activities  preA"  in  order  to  continue 
other  important  parallel  processing  required  for  the  model  to  execute  correctly. 

On  one  flow,  the  acquisition  swim  lane  begins  work  known  as  "Develop  Courses  of  Action"  with 
a  time  distribution  of  30  to  180  days,  with  a  most  likely  value  of  160  days.  Sometimes  the  time  required 
is  often  a  measure  of  the  "novelty  factor"  of  the  program  as  opposed  to  the  ACAT  level.  This  would  be  a 
possible  future  work  extension  of  the  model.  The  "purpose  of  the  COA  is  to  present  the  operational 
MAJCOM  commander  with  acquisition  strategy  options  for  the  selected  materiel  solution  resulting  from 
the  AOAs"  or  other  studies/analyses  per  AFI  63-101.  For  the  non-AOA  programs,  this  step  takes  place 
upon  completion  of  the  additional  analyses  done  in  the  Requirements  swim  lane.  The  COA  serves  "as 
the  basis  for  the  Acquisition  Strategy,  TDS,  T&E  strategy,  LCMP  and  EMA"  per  AFI  63-101. 

Several  other  activities  also  occur  in  parallel  and  will  be  discussed  only  in  generalities.  For 
instance,  the  formation  of  an  Integrated  Test  Team  takes  place  during  this  time  as  well  and  does  its  work 
in  parallel  with  COA  development. 
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In  the  parallel  process  flow,  the  next  step  is  the  development  of  both  the  T&E  strategy  (done  by 


the  Integrated  Test  Team  (ITT))  and  the  Technology  Development  Strategy.  It  is  a  plan  to  assess  the 
maturity  and  viability  of  technologies  being  considered  in  the  "development  of  phase  capabilities 
requirements"  per  AFI  63-101.  This  step  is  "Develop  T&E  strategy  and  Technology  Development 
Strategy."  It  has  a  time  distribution  for  this  task  is  30  to  180  days,  with  a  most  likely  value  of  150  days. 
This  was  validated  by  participants  in  SAF/AQ  and  A35.  The  time  required  is  often  a  measure  of  the 
"novelty  factor"  of  the  program  as  opposed  to  the  ACAT  level.  This  is  another  possible  future  work 
extension  of  the  model. 

It  is  important  to  note  several  items  that  are  not  germane  to  the  level  of  resolution  of  this  part 
of  the  model  or  the  calculation  of  time  elapsed.  Throughout  this  process,  the  PM  is  responsible  to 
ensure  that  his  obligations  and  expenditures  are  OK.  The  contractors  used  in  this  effort  are  typically 
accounted  for  through  a  "level  of  effort"  contract  effort.  The  moneys  involved  are  always  subject  to 
cuts  and  other  uncertainties.  In  this  scenario,  when  this  happens,  the  quality  of  the  effort  diminishes, 
but  the  timeline  does  not  change.  A  possible  future  work  extension  of  the  model  would  be  to 
investigate  quality  settings.  When  moneys  do  impact  the  schedule,  three  factors  play  into  resolving  the 
issue:  the  amount  of  money,  e.g.  more  money  needed  equals  more  time  required;  the  timing  of  the 
request,  e.g.  where  in  the  POM  cycle  does  the  request  come;  and  the  ACAT  level  of  the  program,  e.g. 
higher  level  equals  a  faster  response,  whereas  a  lower  level  takes  longer. 

Upon  completion  of  these  steps  a  "Preferred  System  Concept"  emerges.  It  is  the  sum  total  of  all 
previous  efforts,  e.g.  the  AOA  materiel  preferred  solution,  acquisition  strategy,  T&E  plan,  TDS,  etc. 
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Another  way  to  describe  the  emergence  of  the  preferred  system  concept  is  when  the  MAJCOM 
"Chooses  and  recommends  a  selected  COA"  as  its  next  task.  The  process  for  the  MAJCOM  to  do  so 
requires  30  to  90  days,  with  a  most  likely  duration  of  60  days.  Together,  the  MAJCOM  commander,  and 
theoretically,  the  MDA,  will  jointly  approve  the  COA  99%  of  the  time.  1%  will  be  rejected  and  the 
process  will  end  via  the  model  artifacts  of  "Kill  program  at  selected  COA,"  "End  Simulation  5,"  "Record 
5,"  and  "End  Process  at  COA."  Information  obtained  and  validated  from  official  documents  and  JCIDS 
participant. 

The  requirements  portion  of  the  swim  lane  ends  to  await  the  Acquisition  swim  lane  finishing 
their  activities  and  the  declaration  of  the  MDA  of  accepting  the  MAJCOM's  preferred  COA  and  the 
approval  of  the  acquisition  strategy  and  plans.  When  the  MAJCOM  approves  the  selected  COA,  this 
represents  the  initial  Cost,  Schedule,  and  Performance  baseline  for  the  program,  although  it  is  not 
counted  as  the  program's  official  "start". 
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Figure  74:  Pre-MS  A  Acquisition  swim  lane  after  COA  selection 

From  the  COA  decision  and  also  the  T&E  strategy  tasks,  the  model  waits  until  both  are  complete 
at  “Processes  come  together."  Afterward  the  "Preferred  System  Concept  is  Named."  Next,  the  "Draft 
RFP  Preparation  preA"  step  is  met.  The  process  task,  "Draft  RFP  Preparation  PreA"  has  a  time 
distribution  of  10  to  20  days,  with  a  most  likely  value  of  17  days.  Typically  there  is  some  effort  to  waive 
the  requirement  for  all  of  the  preferred  system  concept  items  and  preliminary  results  will  be  used, 
especially  if  trying  to  meet  a  "target"  MS  A  date  goal,  but  for  purposes  of  model  simplicity,  this  behavior 
will  not  be  modeled.  The  source  of  this  information  is  experience  and  source  documents.  Outputs  from 
this  step  go  to  three  different  tasks,  handled  via  the  "Separate  activities  once  preA"  and  "Separate  again 
PreA,"  with  one  path  going  to  the  "RFP  coordination  process,"  another  to  the  development  of  the 
"Source  Selection  plans  preA,"  and  the  other  to  preparations  related  to  acquisition  panels. 

The  process  task  called  "RFP  coordination  process"  has  a  time  distribution  of  25  to  50  days,  with 
a  most  likely  value  of  45  days.  Some  of  this  coordination  is  done  within  the  branch  of  service  doing  the 
acquisition  and  some  of  it  is  done  with  industry.  The  source  of  this  information  is  interviews,  experience 
and  source  documents. 

Another  process  task,  "Source  selection  plans  preA"  has  a  time  distribution  of  30  to  65  days, 
with  a  most  likely  value  of  60  days.  This  time  distribution  is  influenced  by  the  current  state  of  the 
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contractor's  work  which  is  being  taken  into  consideration  for  the  final  requirements  that  will  be  part  of 


the  future  contracting  effort.  The  source  of  this  information  is  experience  and  published  timelines. 

The  process  task  called  "Preparation  for  Acquisition  Panels"  has  a  time  distribution  of  40  to  60 
days  for  ACAT  I  programs,  with  a  most  likely  value  of  56  days.  For  ACAT  II  and  III  programs,  expect  a 
time  distribution  of  15  to  30  days,  with  a  most  likely  value  of  25  days.  The  majority  of  this  time  is  to  get 
in  synchronization  with  the  fixed  calendar  of  these  panels.  Most  of  the  "work"  has  already  been  done 
prior  to  this  time  and  in  previous  tasks.  The  source  of  this  information  is  an  interview  and  source 
documents. 


Figure  75:  Pre-MS  A  final  funding  check  prior  to  MS  A  approval 


An  artificial  artifact  of  the  model  is  inserted  here  to  check  for  funding.  This  is  in  reality  an  on¬ 
going  process,  but  is  inserted  here  as  it  is  a  necessary  requirement  before  proceeding  to  the  Acquisition 
Panels.  This  decision  point  is  entitled  "Funds  available  PreA"  This  step  reflects  the  fact  that  moneys  for 
additional  development  of  the  concept  are  not  guaranteed  because  they  haven't  been  formally 
budgeted  as  a  separate  line  item.  The  probability  of  this  point  is  75%.  The  reason  this  probability  is  high 
is  that  the  AF  has  already  committed  to  Milestone  A  and  some  anticipation  is  building  over  the 
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development  of  the  concept.  Further,  since  the  moneys  for  this  phase  still  are  controlled  by  the  same 


organization  that  funded  the  pre-MS  A  work,  there  is  going  to  be  some  priority  given  to  funding  and 
completing  the  concept  development. 

If  there  are  not  funds  available,  there  is  a  check  made  to  see  what  kind  of  ACAT  level  the 
program  is  at.  Then  there  is  a  task  to  wait  until  funds  are  available.  This  has  a  time  distribution 
dependent  upon  the  ACAT  level  of  the  program.  For  ACAT  I  programs,  the  "ACAT  I  time  delay"  has  a 
distribution  of  30  to  180  days,  with  a  most  likely  value  of  45  days.  For  the  "ACAT  II  or  ACAT  III  time 
delay,"  a  time  distribution  of  90  to  240  days,  with  a  most  likely  value  of  150  days  is  encountered.  Again, 
this  distribution  is  given  because  of  the  various  sources  of  money  that  can  be  used  or  tapped  as  occasion 
warrants  as  well  as  depending  upon  the  time  of  the  year,  the  amount  of  money  required,  etc. 

After  these  activities  have  completed,  all  of  the  separated  functions  come  back  together.  In 
order  for  this  step  to  occur,  the  "RFP  coordination  process"  and  "source  selection  plans"  must  also  be 
completed.  The  task  will  not  start  until  all  predecessor  activities  are  done.  This  is  an  artificial  queue 
titled  "Complete  predecessor  activities  preA."  It  allows  processes  to  finish  at  different  times,  but  waits 
until  all  are  completed  before  the  program  is  allowed  to  proceed  further. 

The  process  task  entitled  "Acquisition  Panels"  has  a  time  distribution  of  15  to  35  days,  with  a 
most  likely  value  of  30  days.  The  time  distribution  allows  for  delays  and  resolution  of  last  minute  issues 
in  these  events.  Validation  for  this  activity  is  from  official  documentation. 
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Figure  76:  Pre-MS  A  Milestone  Decision  activity 


A  decision  point  entitled  "MDA  Milestone  approval"  has  a  probability  of  99%.  This  probability 
relies  upon  the  confluence  of  all  previous  tasks  preparing  for  the  next  phase  of  acquisition  development. 
The  source  of  this  information  is  official  documents  and  interviews.  If  "no",  the  process  returns  to  the 
"Preparation  for  Acquisition  Panels"  step  to  repeat  the  process.  If  it  is  rejected  twice,  the  process  ends. 
In  essence,  the  sponsoring  MAJCOM  will  withdraw  its  support/funding  and/or  restructure  the  program  - 
going  back  to  the  beginning.  This  is  accomplished  by  first  checking  to  see  if  a  previous  milestone 
decision  was  attempted.  If  not,  a  counter  is  set  and  the  program  returns  to  the  task  of  preparing  for  the 
acquisition  panels  and  repeats  of  those  required  activities.  If  it  has  been  rejected  twice,  the  program  is 
killed  via  the  model  artifacts  of  "End  Simulation  6,"  "Record  7,"  and  "Kill  at  MS  A  decision." 

If  approved  by  the  MDA,  Milestone  "A"  is  declared  at  this  point.  The  "program"  contains  all  of 
the  information,  approval,  and  consent  required  to  proceed  to  the  next  phase  of  activity. 

A  Few  Final  Comments  about  Acquisition  Activities  in  the  Pre-MS  A  Swim  Lane 

The  acquisition  swim  lane  attempts  to  model  the  acquisition  process  for  acquisition  programs. 
Among  the  different  swim  lanes  in  this  model,  it  is  by  far  the  most  studied  in  its  workings  and  outcomes. 
It  is  also  subject  to  the  most  scrutiny  by  outside  parties  trying  to  discern  what  is  "wrong"  with  the 
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system  and  what  to  recommend  as  changes  to  be  in  the  better  interests  of  the  taxpayer.  Not  every 
acquisition  function  is  modeled  or  identified,  rather,  the  focus  of  this  model  is  to  capture  the  events  that 
effect  the  cost  and/or  schedule  outcomes  of  projects. 

It  is  possible  that  to  an  outside  observer  the  Pre-MS  A  Requirements  Swim  Lane  "Analysis"  task 
seems  to  duplicate  acquisition  system  functions.  This  is  true  in  many  respects.  However,  this  is  how  the 
system  has  been  defined. 

The  initial  steps  for  acquisition  in  this  stage  are  somewhat  vague,  but  have  been  defined  as 
clearly  as  possible.  Furthermore,  during  the  Analysis  of  Material  Approaches  that  happens  during  the 
Requirements  Phase,  personnel  from  Acquisition  are  involved  at  lower  levels  of  responsibility.  These  are 
typically  "experts"  working  in  the  Advanced  Concepts  or  Future  Capabilities  offices  located  within  the 
Air  Force's  Materiel  Command.  Only  when  an  activity  looks  like  there  is  going  to  be  long-term 
development  forthcoming  does  the  "system"  kick-in  to  gear. 

The  first  definable  step,  although  not  explicit  in  the  model,  occurs  immediately  after  the  RSR  in 
the  Requirements  Swim  Lane.  At  this  time,  the  Air  Force  is  supposed  to  appoint  a  Milestone  Decision 
Authority  (MDA).  Upon  completion  of  the  ICD,  the  MDA  will  appoint  a  PM  responsible  until  the  program 
is  officially  established  at  MS  B.  However,  at  this  time,  there  is  no  "program  office"  established  and 
relies  upon  other  offices  for  staff,  etc. 

Upon  completion  of  the  AOA  Plan  and  receipt  of  the  ICD,  the  next  major  defined  step  is  entitled 
"Prepare  for  Acquisition  Panels,"  as  discussed  earlier.  This  task  is  not  able  to  begin  until  an  approved 
Initial  Concept  Document  (ICD)  is  available  from  the  requirements  swim  lane.  Undoubtedly,  some 
advance  work  is  done  through  the  efforts  of  those  acquisition  personnel  participating  on  the  High- 
Performance  Team.  But  for  purposes  of  the  model,  we  are  only  concerned  with  the  major  drivers  to 
system  outcomes.  Therefore,  many  activities  will  remain  undocumented.  As  mentioned,  these  efforts 
will  be  usually  done  by  an  organization  known  as  an  advanced  concepts  group  whose  sole  purpose  is  to 
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nurse"  these  projects/ideas  along  until  they  obtain  the  status  of  a  full  program  and  it's  own  separate 


program  office. 

The  Contractor  Pre-MS  A  Swim  Lane 

The  contractor  portion  of  Pre-MS  A  is  not  used  in  the  model  but  that  does  not  mean  no 
contractors  were  involved.  On  the  contrary,  contractors  working  directly  for  the  MAJCOM  conducted 
the  AOA  or  other  studies  as  well  as  numerous  technical  support  contractors  worked  for  the  PM  in 
developing  strategies,  courses  of  action,  etc.  The  uncertainties  of  contract  management  and  other  risks 
are  already  incorporated  in  the  time  distributions  and  probabilities  of  the  other  components  of  the 
model  in  this  pre-A  phase. 

The  Pre-Milestone  B  Swim  Lanes 


This  phase  represents  all  of  the  Pre-MS  B  activities  in  all  four  swim  lanes:  Requirements;  PPBE; 
acquisition;  and  contractors.  The  notations  on  the  figure  above  indicate  which  figure  to  refer  to  in  order 
to  get  detailed  model  information  on  specific  sections  of  the  model.  The  detailed  explanation  for  the 
content  within  the  figure  will  immediately  follow  the  figure. 
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Figure  78:  Pre-MS  B  Early  Requirements  Swim  Lane 


The  first  step  coming  after  MS  A  is  an  artifact  of  the  model,  a  separation  of  programs  that  will 
allow  parallel  processing  in  the  requirements  swim  lane  and  the  acquisition  swim  lane.  The  next  step  is 
"Wait  for  Signal  from  Acquisition."  This  step  is  important  as  it  serves  as  a  time  delay,  waiting  for  the 
acquisition  system  to  award  a  contract.  After  the  contract  is  awarded,  the  other  activities  of  the  swim 
lane  may  begin.  For  practical  purposes,  this  merely  acknowledges  the  need  for  the  requirements  system 
to  ascertain  the  direction  of  the  program  in  development. 

The  first  process  task  of  this  swim  lane  is  entitled  "KPP  Development"  with  a  time  distribution 
ranging  from  the  amount  of  time  equal  to  65%  of  the  Technology  Development  original  contract  length 
to  75%  of  the  Technology  Development  original  contract  length,  with  the  most  likely  amount  being  72% 
of  the  Technology  Development  original  contract  length.  The  task  starts  at  roughly  the  same  time  the 
contract  is  awarded.  The  inputs  to  this  task  are  the  AOA  results,  the  preferred  system  concept 
information  and  also  some  other  preliminary  results  from  Acquisition.  The  source  for  this  information  is 
from  interviews  and  was  validated  by  JCIDS  participant. 

At  the  Milestone  A  decision,  the  MDA  may  also  direct  another  AOA  to  be  conducted  to  update 
or  correct  the  previous  AOA  results,  taking  into  account  any  factors  that  may  have  changed  during  the 
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preceding  phase.  The  probability  of  this  occurring  is  unknown  at  this  time,  however,  for  purposes  of  this 


model,  the  time  to  complete  the  AOA  is  less  than  the  KPP  Development  task  and  is  therefore 
inconsequential  to  the  overall  task.  Any  results  of  the  AOA  will  be  folded  into  the  KPP  Development 
activity. 

An  artifact  of  the  model  will  set  a  variable  to  signal  when  the  KPP  development  was  complete 
follows  this  task  and  will  be  used  later  within  the  acquisition  swim  lane  to  permit  another  process  task 
to  proceed. 

A  decision  point  entitled  "decision  to  pursue  requirements  PreB"  has  a  probability  of  98%.  The 
ultimate  purpose  of  starting  this  process  is  to  end  with  an  approved  Concept  Capability  Document,  CCD. 
The  reason  for  the  high  probability  is  that  the  MDA  has  an  agreement  with  the  MAJCOM-sponsoring 
commander  to  pursue  Milestone  B  and  acquisition  activity  is  already  taking  place.  The  organizational 
momentum  is  difficult  to  stop.  The  source  of  this  information  is  by  inference  and  documented 
materials.  If  "no",  a  decision  point  entitled,  "check  on  conditions,"  is  met  to  see  if  this  program  has 
been  turned  down  twice.  If  "no,"  then  a  decision  variable  will  be  set.  Next,  a  process  task  entitled  "wait 
for  more  favorable  conditions"  is  seen.  The  time  distribution  is  100  to  150  days,  with  a  most  likely  value 
of  115  days.  This  is  to  give  the  acquisition  system  more  time  to  develop  and  mature  the  program 
further  before  making  another  decision.  If  the  decision  is  "no"  a  second  time,  the  program  trips  the 
"check  on  conditions"  decision  point  and  it  is  killed  via  the  model  artifacts  "Record  3,"  "end  simulation 
PreB,"  and  "End  Prior  to  start  of  Requirements  swim  lane  preB"  (not  shown).  This  is  all  placed  into  an 
archive  to  be  revisited  later  by  the  enterprise  system. 
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Figure  79:  Pre-MS  B  Entry  into  formal  requirements  process  at  MAJCOM 


A  task  entitled  "draft  briefing  and  materials"  has  a  time  distribution  of  10  days  to  40  days,  with  a 
most  likely  value  of  31.  The  source  of  this  information  was  derived  from  interview  data  and  validated  by 
JCIDS  participant. 

A  decision  point  entitled  "MAJCOM  A  Letters  Coordinate  and  Concur  PreB"  has  a  probability  of 
90%.  The  source  of  this  information  is  interview  and  later  validation  by  JCIDS  participant.  Assuming  this 
was  a  first  time  rejection  by  the  MAJCOM  "A"  Letters,  the  program  proceeds  to  a  "Check  Condition 
PreB"  step  which  is  a  model  artifact  checking  for  a  failure  flag,  it  then  meets  the  model  artifact  entitled 
"Add  counter  through  feedback  path,"  which  sets  a  variable  indicating  a  failure.  The  probability  of  the 
next  step,  a  decision  point  titled,  "decision  to  pursue,"  is  approximately  85%.  If  successful,  the  next  step 
is  back  toward  the  MAJCOM  "A"  letters,  through  the  task  "Update  Briefing  Materials  PreB."  This  task 
has  a  time  distribution  of  10  to  40  days,  with  a  most  likely  value  of  35  days.  If  not,  the  item  is  killed  and 
archived,  with  the  model  artifacts  "Record  33,"  "End  Simulation  PreB,"  and  "End  prior  to  start  of 
Requirements  swim  lane  PreB." 


302 


Figure  80:  Pre-MS  B  Requirements  swim  lane  MAJCOM  process 

A  task  entitled  "Update  and  schedule  calendar"  has  a  time  distribution  of  3  to  15  days,  with  a 
most  likely  value  of  12  days.  The  source  of  this  information  is  inference  derived  from  interview  data  and 
was  validated  by  JCIDS  participant. 

A  decision  point  entitled  "Pre-RSR  MAJCOM  A8"  has  a  probability  of  99%.  If  "false,"  then  the 
program  proceeds  to  the  "check  condition"  step  as  discussed  with  Figure  79.  The  source  of  this 
information  is  interview  and  was  validated  by  JCIDS  participant. 

A  task  entitled  "Finalize  RSR  and  calendar  items  PreB"  has  a  time  distribution  of  21  to  35  days, 
with  a  most  likely  value  of  28  days.  The  source  of  this  information  is  from  an  interview  and  validated  by 
JCIDS  participant  and  the  official  Document  Timeline  Calculator. 

A  decision  point  entitled  "RSR  HQ  USAF  A5R  PreB"  has  a  probability  of  98%.  The  source  of  this 
information  is  an  interview.  If  the  answer  to  this  decision  point  is  "no",  the  process  returns  to  the 
originator  via  the  "check  condition"  step.  The  RSR  must  include  the  funding  strategy  for  the  remaining 
phases  of  Acquisition.  Note  that  it  does  not  include  a  guarantee  of  funds  -  rather  it  is  a  strategy  or  best 
guess  or  promise  to  fund.  If  the  Joint  Potential  Designator  needs  to  be  updated,  it  is  done  at  this  point. 
However,  the  model  assumes  nothing  changes.  ACAT  I  activities  have  a  100%  chance  of  getting  joint 
interest.  ACAT  II  activities  are  usually  designated  as  "joint  information"  and  any  comments  are  taken 
under  advisement,  while  ACAT  III  activities  are  designated  "independent"  AF  only  and  are  distributed  to 
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the  other  services  as  a  courtesy  only  for  comment  and  review.  The  joint  information  was  validated  by 


A5  personnel  and  the  official  Document  Timeline  Calculator. 

At  this  point,  the  process  waits  for  the  results  of  the  Early  Operational  Assessment.  The  task 
"Wait  for  EOA  completion,"  waits  until  a  variable  is  set  within  the  acquisition  swim  lane  that  the  EOA 
was  successful.  This  step  was  discovered  during  the  validation  phase  discussing  the  model  with 
individuals  from  both  JCIDS  and  SAF/AQ. 


Returning  to  the  process  flow,  the  next  task  is  called  "form  high  performance  team  preB"  has  a 
time  distribution  of  30  to  45  days,  with  a  most  likely  value  of  41  days.  The  source  of  this  information  is 
an  interview  and  validated  by  JCIDS  participant  and  the  official  Document  Timeline  Calculator. 

The  task  called  "High-Performance  Team  (HPT)  work"  has  a  time  distribution  of  5  to  7  days,  with 
a  most  likely  value  of  6  days.  The  source  of  this  information  is  an  interview  and  later  validated  by  JCIDS 
participant.  The  product  of  this  event  is  a  "draft  document". 

At  this  point  a  variable  is  set,  "Declaring  the  KPPs  are  ready  for  Acquisition  preB,"  in  order  to 
trigger  some  key  process  work  in  the  acquisition  swim  lane.  This  is  an  artifact  of  the  model,  but  was 
discussed  as  an  important  issue  during  the  validation  activity  in  discussions  with  JCIDS  participants  and 
acquisition  personnel. 

At  this  point,  a  decision  point  entitled  "Determine  document  approval  path  preB"  separates  the 
activity  into  three  separate  paths  to  approval  depending  upon  the  Joint  Potential  Designator,  e.g.  a 
"rough"  surrogate  for  the  ACAT  level,  of  the  activity.  The  model  separates  these  based  on  the  previously 
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designated  ACAT  level.  ACAT  I  programs  go  to  the  "Joint  Interest  preB"  step.  ACAT  II  programs  go  to  the 


"Joint  Integration  preB"  step  and  ACAT  III  programs  go  to  the  "Independent  Document  preB"  step. 

Following  the  completion  of  these  steps,  which  will  be  discussed  in  detail  shortly,  the  CCD 
completion  time  is  recorded  as  an  artifact  of  the  model  with  the  step,  "Record  CCD." 


Figure  82:  Pre-MS  B  Requirements  Independent  Document  process 

The  task  called  "Draft  document  Indep  preB"  has  a  time  distribution  of  30  to  60  days,  with  a 
most  likely  value  of  55  days  and  is  really  an  "advanced"  draft  of  the  document  previously  worked  on  by 
the  High  Performance  team.  This  is  the  time  for  internal  coordination  and  clean-up.  The  source  of  this 
information  is  an  interview  and  validated  by  JCIDS  participants  as  well  as  by  the  official  Document 
Timeline  Calculator.  In  reality,  at  this  point,  information  is  passed  to  the  acquisition  system  for 
preparatory  work. 

The  task  called  "air  staff  processes  indep  preB"  has  a  time  distribution  of  21  to  42  days,  with  a 
most  likely  value  of  29  days.  The  source  of  this  information  is  interview  and  official  documentation.  A 
few  days  of  internal  processing  time  and  a  maximum  21-day  review  (with  the  possibility  of  an  extension) 
form  the  basis  of  the  time  distribution.  The  information  was  later  validated  by  a  JCIDS  participant  and 
the  official  Document  Timeline  Calculator. 

The  decision  point  entitled  "Critical  comments  Indep  PreB"  has  a  probability  of  95%.  The  source 
of  this  information  is  an  interview  and  validated  by  JCIDS  participant.  If  there  are  no  critical  comments, 
the  task  proceeds  to  the  AFROC  Preparations  step. 
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The  task  called  "comment  resolution  indep  preB"  has  a  time  distribution  of  15  to  45  days,  with  a 
most  likely  value  of  45  days.  This  is  where  the  sponsor  resolves  0-663  level  comments.  The  source  of 
this  information  is  interview  and  validation  by  JCID  participant  and  the  official  Document  Timeline 
Calculator. 

The  decision  point  entitled  "MAJCOM  approval  indep  preB"  has  a  probability  of  99%.  The 
source  of  this  information  is  interview  and  later  validation  by  JCIDS  participant.  If  the  answer  is  no,  the 
next  step  remains  comment  resolution  and  information  is  passed  into  the  budgeting  and  programming 
system  to  deal  with  the  financial  ramifications.  Usually,  this  means  the  activity  is  put  on  "hold"  for  a 
year,  probably  the  result  of  some  "critical  comments"  that  were  not  immediately  resolved.  This  is 
represented  by  the  step,  "Hold  for  a  year  later  in  process  Indep  preB."  It  has  a  time  distribution  of  270 
to  365  days,  with  a  most  likely  value  of  300  days.  If  the  answer  is  yes,  the  activity  proceeds  to  the  next 
step. 

The  task  called  "AFROC  preparations  Indep  preB"  has  a  time  distribution  of  30  to  60  days,  with  a 
most  likely  value  of  45  days.  The  source  of  this  information  is  an  interview  and  the  official  Document 
Timeline  Calculator. 

The  decision  point  "AFROC  decision  indep  preB"  has  a  probability  of  90%.  Of  those  90%,  20%  to 
30%  will  have  "actions"  (Post  AFROC  "Go-do"  actions)  to  accomplish,  see  step  "Post  AFROC  actions 
Indep  preB"  and  must  return  to  the  AFROC  within  0  to  15  days,  with  a  most  likely  value  of  11  days.  The 
source  is  the  official  Document  Timeline  Calculator. 

If  the  initial  answer  at  the  AFROC  is  "no,"  there  is  a  99%  chance  the  activity  is  "dead"  and  the 
document  is  archived.  First,  there  is  a  check  to  see  if  the  rejection  is  the  first  time  or  not.  This  is  done  at 
the  step  entitled,  "Check  for  previous  path  indep  PreB."  The  model  sets  a  variable  in  "Set  tracking  Indep 
PreB."  The  next  step  is  "Dead  activity  Indep  PreB."  This  step  has  a  probability  of  99%  being  killed.  If 

63  0-6:  refers  to  a  Colonel  or  Captain  (for  the  Navy). 
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not,  the  program  goes  back  to  the  step  "comment  resolution  Indep  PreB."  During  validation,  the  source 


indicated  he  had  never  seen  anything  go  back  through  the  AFROC  a  2nd  time  based  on  his  25+  years  of 
experience.  Therefore,  the  path  taken  by  the  less  than  likely  1%  of  documents  would  be  back  to  the 
MAJCOM  for  approval  through  the  comment  resolution  process  and  follow  the  normal  process  beyond 
that.  Otherwise,  the  activity  is  "dead"  and  this  is  represented  by  the  model  artifacts  "End  Simulation 
PreB  1,"  "Record  23,"  and  "Death  at  AFROC  Indep  PreB."  The  source  of  this  information  is  an  interview 
as  well  as  review  of  official  process  documents.  It  has  been  validated  by  a  JCIDS  participant. 

At  this  point  the  CCD  is  approved  and  the  program  resumes  the  process  flow  as  depicted  in 
Figure  81. 


Figure  83:  Pre-MS  B  Requirements  swim  lane  Joint  Integration  process.  Part  I 

The  task  called  "draft  document  joint  integ  preB"  has  a  time  distribution  of  30  to  60  days,  with  a 
most  likely  value  of  55  days.  This  is  really  an  "advanced"  draft  of  the  document  previously  worked  on  by 
the  High  Performance  team.  It  is  the  time  for  internal  coordination  and  clean-up.  The  source  of  this 
information  is  an  interview  and  validated  by  JCIDS  participant  as  well  as  by  the  official  Document 
Timeline  Calculator.  In  reality,  information  is  passed  to  the  acquisition  system  for  preparatory  work. 

The  task  called  "air  staff  processes  joint  integ  preB"  has  a  time  distribution  of  21  to  42  days  with 
a  most  likely  value  of  29  days.  The  source  of  this  information  is  interview  and  official  documentation.  A 
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few  days  of  internal  processing  time  and  a  maximum  21-day  review  (with  the  possibility  of  an  extension) 


form  the  basis  of  the  time  distribution.  The  source  of  this  information  was  validated  by  JCIDS  participant 
and  the  official  Document  Timeline  Calculator. 

The  decision  point  entitled  "Critical  comments  joint  integ  preB"  has  a  probability  of  95%.  The 
source  of  this  information  is  an  interview  and  validated  by  JCIDS  participant.  If  there  are  no  critical 
comments,  the  task  proceeds  to  the  "Document  review  phase  joint  integ  preB." 

The  task  called  "comment  resolution  joint  integ  preB"  has  a  time  distribution  of  15  to  45  days, 
with  a  most  likely  value  of  30  days.  This  is  where  the  sponsor  resolves  0-6  level  comments.  The  source 
of  this  information  is  interview  and  validation  by  JCIDS  participant  and  the  official  Document  Timeline 
Calculator. 

The  decision  point  entitled  "MAJCOM  approval  joint  integ  preB"  has  a  probability  of  99%.  The 
source  of  this  information  is  interview  and  later  validation  by  JCIDS  participant.  If  the  answer  is  no,  the 
next  step  remains  comment  resolution  and  information  is  passed  into  the  budgeting  and  programming 
system  to  deal  with  the  financial  ramifications.  Usually,  this  means  the  activity  is  put  on  "hold"  for  a 
year,  probably  the  result  of  some  "critical  comments"  that  were  not  immediately  resolved.  This  step  is 
entitled  "Hold  for  a  year  later  in  process  joint  integ  preB"  with  a  time  distribution  of  270  to  365  days, 
with  a  most  likely  value  of  300  days.  If  the  answer  is  yes,  the  activity  proceeds  to  the  next  step. 

The  step  "Document  review  phase  joint  integ  preB"  is  applicable  to  50%  of  the  documents 
seeking  approval.  The  other  50%  proceed  directly  to  the  Interoperability  Certification  step.  The  next 
step,  for  those  that  require  it,  is  called  the  "Document  Review  Phase  2  Flag  level  joint  integ  preB".  This 
activity  is  taking  place  because  there  were  "critical  comments"  that  were  not  resolved  during  the  initial 
round  and  the  MAJCOM  sponsor  determined  to  press  ahead  anyway.  This  step  has  a  time  distribution 
of  21  to  42  days,  with  a  most  likely  value  of  34  days.  This  has  been  validated  by  the  Official  Document 
Timeline  Calculator. 
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The  next  step  is  another  round  of  the  sponsor  "Resolving  Flag  Level  Comments  joint  integ  preB. 


The  time  distribution  is  15  to  30  days,  with  a  most  likely  value  of  28  days.  This  was  validated  by  the 
official  Document  Timeline  Calculator. 


The  decision  point  entitled  "MAJCOM  approval  joint  integ  preB"  has  a  probability  of  99%.  The 
source  of  this  information  is  interview  and  later  validation  by  JCIDS  participant.  If  the  answer  is  no,  the 
next  step  remains  comment  resolution  and  information  is  passed  into  the  budgeting  and  programming 
system  to  deal  with  the  financial  ramifications.  Usually,  this  means  the  activity  is  put  on  "hold"  for  a 
year,  probably  the  result  of  some  "critical  comments"  that  were  not  immediately  resolved.  This  step  is 
titled  "Hold  for  a  year  later  in  process  2nd  time  joint  integ  preB."  This  step  has  a  time  distribution  of  270 
to  300  days,  with  a  most  likely  value  of  300  days.  If  the  answer  is  yes,  the  activity  proceeds  to  the  next 
step.  This  step  was  validated  by  the  official  Document  Timeline  Calculator. 

The  step  called  "Interoperability  Certification  joint  integ  preB"  has  a  time  distribution  of  10  to  20 
days,  with  a  most  likely  value  of  15  days.  The  validation  came  from  the  official  Document  Timeline 
Calculator. 

The  task  called  "AFROC  preparations  joint  integ  preB"  has  a  time  distribution  of  30  to  60  days, 
with  a  most  likely  value  of  45  days.  The  source  of  this  information  is  an  interview  and  the  official 
Document  Timeline  Calculator. 

The  decision  point  "AFROC  decision  joint  integ  preB"  has  a  probability  of  90%.  Of  those  90%, 
20%  to  30%  will  have  "actions"  (Post  AFROC  "Go-do"  actions)  to  accomplish.  This  possibility  is  called 
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"Post  AFROC  actions  joint  integ  preB."  The  step  "Accomplish  Post  AFROC  actions  joint  integ  preB" 
includes  returning  to  the  AFROC  within  0  to  15  days,  with  a  most  likely  value  of  11  days.  If  the  initial 
answer  at  the  AFROC  decision  is  "no,"  there  is  a  99%  chance  the  activity  is  "dead"  and  the  document  is 
archived.  During  validation  of  the  model,  the  source  indicated  he  had  never  seen  anything  go  back 
through  the  AFROC  a  2nd  time  based  on  his  25+  years  of  experience.  The  path  taken  by  the  less  than 
likely  1%  of  documents  would  be  back  to  the  MAJCOM  for  approval  through  the  comment  resolution 
process  and  follow  the  normal  process  beyond  that.  For  the  logic  of  the  model  to  remain  intact,  the 
program  is  first  checked  to  see  if  it  has  previously  been  rejected.  If  not,  a  variable  is  set.  Then  it  meets 
the  step  "Dead  activity  joint  integ  preB"  with  a  99%  probability  of  being  killed  outright.  If  not,  it  is  then 
set  back  to  the  comment  resolution  step.  Otherwise,  the  program  is  killed  via  the  model  artifacts  "End 
Simulation  preB  1,"  "Record  22,"  and  "Death  at  AFROC  joint  integ  preB."  The  source  of  this  information 
is  an  interview,  the  official  Document  Timeline  Calculator  as  well  as  review  of  official  process 
documents.  It  has  been  validated  by  JCIDS  participant. 

The  step  "Document  signing  and  validation  joint  integ  preB"  is  because  the  AFROC  then  requires 
14  to  30  days,  with  a  most  likely  value  of  26  days,  to  get  the  document  signed  and  validated  across  the 
AF  structure.  The  step  "Final  AFROC  approval  joint  integ  preB"  has  a  99%  chance  to  be  approved  by  the 
AFROC  without  issues.  The  remaining  1%  have  issues  requiring  resolution,  e.g.  step  "Final  AFROC 
resolution  joint  integ  preB,"  typically  requiring  42  to  60  days  to  resolve,  with  a  most  likely  value  of  48 
days. 

At  this  point  the  CCD  is  approved  and  re-enters  the  process  flow  as  depicted  in  Figure  81. 
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Figure  85:  Pre-MS  B  Requirements  swim  lane  Joint  Interest  process.  Part  I 

The  task  called  "draft  document  preB  joint  interest"  has  a  time  distribution  of  30  to  60  days, 
with  a  most  likely  value  of  55  days.  It  is  really  an  "advanced"  draft  of  the  document  previously  worked 
on  by  the  High  Performance  team.  This  is  the  time  for  internal  coordination  and  clean-up.  The  source  of 
this  information  is  an  interview  and  validated  by  JCIDS  participant  as  well  as  by  the  official  Document 
Timeline  Calculator.  Information  is  also  passed  to  the  acquisition  system  for  preparatory  work,  but  is 
not  done  explicitly  in  this  model. 

The  task  called  "air  staff  processes  joint  int  preB"  has  a  time  distribution  of  21  to  42  days,  with  a 
most  likely  value  of  25  days.  The  source  of  this  information  is  interview  and  official  documentation.  A 
few  days  of  internal  processing  time  and  a  maximum  21-day  review,  with  the  possibility  of  an  extension, 
form  the  basis  of  the  time  distribution.  The  source  of  this  information  was  validated  by  JCIDS  participant 
and  the  official  Document  Timeline  Calculator. 

The  decision  point  entitled  "critical  comments?  Joint  int  preB"  has  a  probability  of  95%.  The 
source  of  this  information  is  an  interview  and  validated  by  JCIDS  participant.  If  there  are  no  critical 
comments,  the  task  proceeds  to  the  AFROC  Preparations  step. 

The  task  called  "Comment  resolution  joint  int  preB"  has  a  time  distribution  of  15  to  45  days, 
with  a  most  likely  value  of  30  days.  This  is  where  the  sponsor  resolves  0-6  level  comments.  The  source 
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of  this  information  is  interview  and  validation  by  JCIDS  participant  and  the  official  Document  Timeline 


Calculator. 

The  decision  point  entitled  "MAJCOM  approval?  Joint  int  preB"  has  a  probability  of  99%.  The 
source  of  this  information  is  interview  and  later  validation  by  JCIDS  participant.  If  the  answer  is  "no," 
the  next  step  remains  comment  resolution  and  information  is  passed  into  the  budgeting  and 
programming  system  to  deal  with  the  financial  ramifications.  Usually,  this  means  the  activity  is  put  on 
"hold"  for  a  year,  probably  the  result  of  some  "critical  comments"  that  were  not  immediately  resolved. 
This  is  represented  by  the  step  "hold  for  a  year  PreB"  with  a  time  distribution  of  270  to  365  days,  with  a 
most  likely  value  of  300  days.  If  the  answer  is  yes,  the  activity  proceeds  to  the  next  step. 

The  task  called  "AFROC  preparations  joint  int  preB"  has  a  time  distribution  of  30  to  60  days,  with 
a  most  likely  value  of  45  days.  The  source  of  this  information  is  an  interview  and  the  official  Document 
Timeline  Calculator. 

The  decision  point  "AFROC  decision  joint  int  preB"  has  a  probability  of  90%.  Of  those  90%,  20% 
to  30%  will  have  "actions"  (Post  AFROC  "Go-do"  actions)  to  accomplish.  This  is  represented  by  "Post 
AFROC  actions  joint  int  preB."  Those  programs  with  actions  to  accomplish,  e.g.  "Post  AFROC  actions" 
must  return  to  the  AFROC.  It  has  a  time  distribution  of  0  to  15  days,  with  a  most  likely  value  of  11  days. 
If  the  initial  answer  is  "no,"  there  is  a  99%  chance  the  activity  is  "dead"  and  the  document  is  archived. 
During  validation,  the  source  indicated  he  had  never  seen  anything  go  back  through  the  AFROC  a  2nd 
time  based  on  his  25+  years  of  experience.  This  is  represented  by  first  checking  to  see  if  the  program 
had  been  rejected  at  the  AFROC  before.  If  not,  a  flag  was  set,  e.g.  "Set  tracking  point  int  preB."  Then 
the  decision  point,  "Dead  Activity  joint  int  preB"  has  a  99%  probability  that  the  program  would  be  killed 
anyway.  The  path  taken  by  the  less  than  likely  1%  of  documents  would  be  back  to  the  MAJCOM  for 
approval  through  the  comment  resolution  process  and  follow  the  normal  process  beyond  that.  The 
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source  of  this  information  is  an  interview  as  well  as  review  of  official  process  documents.  It  has  been 


validated  byJCIDS  participant. 

The  next  step  is  applicable  to  50%  of  the  documents  seeking  approval.  The  other  50%  proceed 
directly  to  the  Functional  Capabilities  Board.  This  is  called  the  "Document  Review  Phase  2  Flag  level 
PreB."  This  activity  is  taking  place  because  there  were  "critical  comments"  that  were  not  resolved 
during  the  initial  round  and  the  MAJCOM  sponsor  determined  to  press  ahead  anyway.  This  step  has  a 
time  distribution  of  21  to  42  days,  with  a  most  likely  value  of  38  days.  This  has  been  validated  by  the 
Official  Document  Timeline  Calculator. 


Figure  86:  Pre-MS  B  Requirements  swim  lane  Joint  Interest  process,  part  II 

The  next  step  is  another  round  of  the  sponsor  "Resolving  Flag  Level  Comments  PreB."  The  time 
distribution  is  15  to  30  days,  with  a  most  likely  value  of  27  days.  This  was  validated  by  the  official 
Document  Timeline  Calculator. 

The  decision  point  entitled  "MAJCOM  approval  PreB"  has  a  probability  of  99%.  The  source  of 
this  information  is  interview  and  later  validation  by  JCIDS  participant.  If  the  answer  is  no,  the  next  step 
remains  comment  resolution  and  information  is  passed  into  the  budgeting  and  programming  system  to 
deal  with  the  financial  ramifications.  Usually,  this  means  the  activity  is  put  on  "hold"  for  a  year, 
probably  the  result  of  some  "critical  comments"  that  were  not  immediately  resolved.  This  step  is  called 
"Hold  for  a  year  later  in  process"  with  a  time  distribution  of  270  to  365  days,  with  a  most  likely  value  of 
300  days.  If  the  answer  is  yes,  the  activity  proceeds  to  the  next  step. 
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Next  is  the  "Functional  Capabilities  Board  PreB"  for  preparation  and  validation.  This  step  has  a 


time  distribution  of  7  to  21  days,  with  a  most  likely  value  of  14  days.  This  is  considered  a  very  difficult 
"scrub"  of  the  activity.  The  model  is  programmed  to  assume  all  documents  proceed  without  problem  to 
the  next  step64.  This  step  was  validated  by  JCIDS  participant,  A5  participant,  and  the  official  Document 
Timeline  Calculator. 

The  "Joint  Capabilities  Board  PreB"  requires  another  7  to  21  days  in  preparation  after  the  FCB, 
with  a  most  likely  value  of  14  days.  Following  this  is  logic,  titled  "JCB  issues  PreB,"  where  85%  that  meet 
the  JCB  board  go  on  to  the  next  step.  The  remaining  15%  have  issues  to  resolve,  titled  "Resolve  JCB 
issues  PreB,"  typically  taking  10  to  20  days,  with  a  most  likely  value  of  15  days,  before  reporting  back  to 
the  JCB.  However,  the  likelihood  of  another  set  of  issues  arising  at  the  second  meeting  of  the  JCB  is  so 
remote  that  the  model  does  not  consider  it  at  all. 

The  JROC  requires  14  to  30  days,  with  a  most  likely  value  of  25  days,  in  preparations,  e.g.  mostly 
calendar  scheduling  issues,  as  noted  in  the  step  titled,  "JROC  Preparations  PreB."  At  the  decision  point 
"JROC  PreB,"  98%  are  approved  without  issues.  The  remaining  2%  have  issues  requiring  resolution, 
typically  requiring  42  to  60  days  to  resolve,  with  a  most  likely  value  of  51  days,  as  shown  in  the  process 
step  "Resolve  JROC  issues  PreB." 

At  this  point  the  CCD  is  approved  and  the  program  resumes  the  process  flow  as  depicted  in 
Figure  81. 

Following  the  approval  of  the  CCD,  it  may  become  apparent  that  the  CCD  needs  to  be  updated. 
The  formal  process  allows  for  this  possibility,  however,  the  model  does  not  for  reasons  of  simplicity. 

64  Unfortunately,  this  is  not  the  case.  This  error  was  discovered  while  preparing  this  dissertation  for  publication. 
The  actual  data  is  that  70%  that  meet  the  board  go  on  to  the  next  step.  The  other  30%  have  issues  to  resolve, 
typically  taking  10  to  20  days,  with  the  most  likely  value  of  15  days  before  reporting  back  to  the  FCB.  However,  the 
likelihood  of  another  set  of  issues  arising  is  so  remote  that  it  is  assumed  to  have  a  probability  of  zero.  Given  that 
the  magnitude  of  this  error  is  on  the  order  of  a  handful  of  days  versus  the  end  result  on  the  order  of  thousands  of 
days,  it  is  judged  that  the  overall  results  in  the  dissertation  are  still  valid. 
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Additional  information  is  presented  here  to  help  the  reader  better  understand  this  aspect  of  the 
process.  CCD  updates  are: 

"...often  a  result  of  unforeseen  program  events  (i.e.,  altering  KPPs,  budget  cuts,  significant 
schedule  delays,  technology  maturity,  leadership  intervention,  acquisition  strategy  changes, 
etc.).  Sponsors  may  update  the  CCD  before  or  after  Milestone  B.  Document  preparation, 
format,  review,  validation,  approval,  and  archiving  of  subsequent  updates  are  normally  the 
same  as  the  original  CCD."  (AFI10-601,  pg  35) 

Joint  interest  CCDs  must  go  through  the  formal  process  to  the  JROC  for  approval.  There  is  some 
latitude  to  eliminate  some  staffing  steps  to  get  to  the  JROC,  but  that  is  by  special  request.  All  other 
CCDs  do  not  need  to  go  through  the  joint  process  for  approval. 

Regardless  of  either  having  an  updated  CCD  or  the  initial  CCD  done,  the  goal  of  the 
requirement's  system  is  to  have  the  CCD  delivered  to  the  MDA  no  later  than  60  days  prior  to  the 
scheduled  MS  B.  This  is  another  potential  quality  check  to  test  in  the  model  and  is  reserved  for  future 
work. 


Figure  87:  Pre-MS  B  early  acquisition  swim  lane  activities 


The  first  step  in  this  phase  is  entitled  "RFP  release  and  Source  Selection  PreB".  It  has  a  time 
distribution  of  90  to  180  days,  with  a  most  likely  value  of  160  days.  The  main  assumption  is  that  there 
will  be  no  sole  source  awards  and  that  sole  source  options  are  not  part  of  the  acquisition  strategy 
completed  in  the  last  phase.  Funding  must  be  in  place  along  with  the  MS  A  declaration.  The  source  for 
this  information  is  experience,  interviews  and  documentation.  It  was  validated  via  acquisition  personnel 
from  SAF/AQ. 
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A  decision  point  entitled  "Protest  award  PreB"  has  a  probability  of  20%.  The  source  of  this 


information  is  open  source  materials,  media,  and  other  documents.  If  "yes"  a  delay  is  encountered 
while  appropriate  agencies  review  the  process.  The  delay,  titled  "Delay  for  Protest  review  PreB"  can  be 
between  30  and  60  days,  with  a  most  likely  value  of  50  days.  Afterwards,  a  decision  point  entitled 
"Protest  Upheld"  is  reached.  Based  on  feedback  from  SAF/AQ  personnel  during  the  validation  of  the 
model,  the  probability  of  this  step  is  40%.  If  "yes"  the  source  selection  process  is  repeated.  If  "no",  the 
process  task  of  "Scope  and  Award  Technology  Development  contracts"  is  next. 

A  task  entitled  "Scope  and  Award  Technology  Development  contracts"  has  a  time  distribution  of 
30  to  120  days,  with  a  most  likely  value  of  100  days.  This  duration  is  dependant  upon  the  complexity  of 
the  required  task  as  well  as  if  the  study  can  be  exercised  as  a  task  or  option  on  an  existing  contract 
vehicle  or  if  a  sole  source  or  other  contracting  mechanism  is  required.  However,  speed  is  favored.  The 
time  duration  associated  with  the  length  of  the  contract  for  technology  development  has  a  distribution 
based  upon  the  ACAT  level  of  the  program.  ACAT  I  programs  have  a  contract  duration  ranging  from  365 
to  2190  days,  with  the  most  likely  value  of  1980  days.  ACAT  II  programs  have  a  contract  duration 
ranging  from  365  to  2190  days,  with  the  most  likely  value  of  1365  days.  ACAT  III  programs  have  a 
contract  duration  ranging  from  365  to  2190  days,  with  the  most  likely  value  of  480  days.  The  source  of 
this  information  is  by  inference  and  experience.  Additional  credence  can  be  found  in  official  process 
documentation.  Validation  of  these  assumptions  was  received  from  personnel  in  SAF/AQ. 

The  process  flow  from  the  previous  step  goes  into  two  different  places.  First,  it  goes  into  the 
Contractor  Swim  Lane  -  reflecting  the  work  a  contractor  is  doing  -  to  be  described  later.  Second,  parallel 
processes  are  initiated  to  prepare  for  moving  the  program  into  the  next  phase  of  development. 
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Figure  88:  Pre-MS  B  Acquisition  costing  and  acquisition  planning 

From  the  split  flow  in  Figure  87,  the  first  activity  is  a  queue  entitled,  "Wait  for  signal  for  Costing 
and  Acquisition  Planning  activities  preB."  This  signal  will  come  from  the  contractor  swim  lane  indicating 
a  certain  percentage  of  the  contract  is  elapsed,  which  will  be  discussed  hereafter.  It  is  a  time  delay  as 
these  activities  will  not  start  until  near  the  end  of  a  contract  and  in  preparation  of  a  Milestone  B 
declaration. 

The  next  step  is  an  artifact  of  the  model,  requiring  parallel  processing.  This  allows  both  the  cost 
exercises  as  well  as  the  acquisition  planning  activities  to  proceed  simultaneously.  The  branch  going  to 
the  cost  area  will  be  split  again  to  allow  three  separate  costing  activities  to  proceed  in  parallel. 

The  process  task  entitled  "Acquisition  Planning  Activities  PreB"  has  a  time  distribution  of  120  to 
250  days,  with  a  most  likely  value  of  240  days  for  ACAT  I  programs.  For  ACAT  II  or  ACAT  III  programs,  the 
time  distribution  is  120  to  250  days,  with  a  most  likely  value  of  185  days.  The  source  of  this  information 
is  interviews  and  published  timelines  and  official  documentation.  It  was  validated  by  acquisition 
personnel. 

The  three  separate  costing  tasks,  "Program  Office  Cost  Estimate  PreB"  has  a  time  distribution  of 
60  to  90  days,  with  a  most  likely  value  of  65  days.  The  "Contractor  Cost  Estimate  PreB"  has  a 
distribution  of  45  to  90  days,  with  a  most  likely  value  of  50  days.  The  process  task,  "Independent  Cost 
Estimate  PreB"  has  a  distribution  of  30  to  60  days,  with  a  most  likely  value  of35  days.  The  source  of  this 
information  is  acquisition  personnel  and  validation  was  obtained  from  other  acquisition  personnel. 
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Figure  89:  Pre-MS  B  Contract  start-up  activities 

The  initial  process  step  in  this  swim  lane  is  called  "Contract  Start-up  PreB."  It  has  a  time 
distribution  of  30  to  45  days,  with  a  most  likely  value  of  42  days.  This  is  regardless  of  the  size  and 
complexity  of  the  overall  task.  This  consists  of  the  preliminary  efforts  to  staff  the  activity  and  organize 
appropriately.  The  source  of  this  information  is  experience  and  source  documentation.  It  was  validated 
by  acquisition  personnel. 

As  an  artifact  of  the  model,  a  variable  is  set  to  record  the  "start"  of  the  contract.  Next,  a  queue 
is  met  entitled,  "Wait  for  T&E  start."  This  queue  waits  for  a  signal  from  the  contractor  swim  lane.  The 
signal  is  triggered  after  a  certain  period  of  contract  time  has  elapsed.  Additionally,  the  KPP  development 
must  be  completed  as  discussed  in  the  requirements  swim  lane  before  the  program  can  be  released 
from  the  queue.  The  specifics  on  the  T&E  signal  will  be  discussed  later.  This  information  was  discovered 
during  the  validation  phase  of  the  model  when  working  with  acquisition  personnel. 


Figure  90:  Pre-MS  B  Acquisition  swim  lane  Systems  Engineering  activities 

Systems  Engineering  activities  are  key  elements  in  systems  development.  It  includes  many 
testing  activities  and  reviews.  The  model  acknowledges  these  activities  as  it  assists  with  the 
management  of  the  contractor  activity. 

Upon  completion  of  any  design  work,  which  is  not  explicitly  model,  but  assumes  to  be 
happening  as  part  of  the  time  elapsed  on  the  contract,  vital  test  and  evaluation  activities  take  place.  As 


318 


mentioned  earlier,  the  testing  done  during  this  phase  cannot  begin  prior  to  the  completion  of  the  KPP 


development  activity  of  the  Requirements  Swim  Lane  AND  receiving  a  trigger  from  the  Contractor  swim 
lane  of  reaching  a  percentage  of  scheduled  contract  time  elapsed. 

The  task  "Developmental  Test  and  Evaluation"  is  modeled  as  having  a  time  distribution  based 
upon  ACAT  levels.  ACAT  I  programs  require  25%  of  scheduled  contract  length  before  starting  DT&E.  The 
actual  time  distribution  is  based  upon  a  triangular  distribution  around  the  25%  of  the  scheduled  contract 
length,  where  the  range  is  75%  to  110%  of  the  recommended  DT&E  start  time,  with  the  most  likely 
being  the  25%  of  the  scheduled  contract  length.  ACAT  II  and  ACAT  III  programs  require  15%  of  the 
scheduled  contract  length,  with  a  similar  triangular  distribution.  This  was  validated  in  speaking  with 
acquisition  personnel. 

After  developmental  testing,  a  decision  point  "trades  needed"  is  met.  This  has  a  probability  of 
70%.  If  "yes"  a  process  task  called  "Dev  testing  rework  and  delay"  is  met.  This  task  has  a  distribution  of 
30  to  180  days,  with  a  most  likely  value  of  90  days.  Future  work  should  also  include  automatic  1%  cost 
penalty  to  the  contract  costs.  Otherwise,  the  process  proceeds  to  the  next  step. 

The  Early  Operational  Assessment  is  a  second  testing  opportunity.  The  EOA  must  be  completed 
prior  to  the  formation  of  the  HPT  in  the  Requirements  Swim  Lane.  The  task  EOA  duration  is  10%  of  the 
scheduled  contract  length.  The  actual  duration  of  the  task  is  based  upon  a  triangular  distribution 
around  the  10%  of  time.  The  range  is  from  75%  of  the  testing  time  through  110%  of  the  testing  time. 
This  was  validated  by  acquisition  personnel.  Upon  successful  completion  of  the  EOA,  a  variable  is  set  to 
announce  its  completion,  so  that  the  HPT  work  may  begin. 

A  decision  point  called  "Additional  adjustments"  comes  next.  This  has  a  probability  of  50%. 
Meaning  that  there  is  a  50%  there  will  need  to  be  some  additional  work  done  to  correct  things  found  in 
the  EOA.  If  "yes"  a  process  task  called  "EOA  Rework  and  Delay"  is  met.  This  task  has  a  distribution  of  30 
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to  180  days,  with  a  most  likely  value  of  90  days.  For  future  work,  this  would  cause  the  program  to  incur 


an  automatic  2%  cost  penalty  to  the  contract  costs.  Otherwise,  the  process  proceeds  to  the  next  step. 

The  "System  Requirements  Review"  follows  at  the  completion  of  the  testing  activities.  This 
decision  point  has  a  probability  of  65%.  If  "yes",  the  step  "SRR  rework  and  delay"  has  a  time  distribution 
of  60  to  180  days,  with  a  most  likely  value  of  160  days. 

The  end  result  is  the  approved  "System  Performance  Specification".  This  "result"  will  consist  of 
plans,  specifications,  studies,  and  rudimentary  component-level  prototypes  that  will  be  used  in  the  next 
phase  of  system  development.  It  is  also  a  pre-requisite  for  completing  the  current  milestone  activities 
and  several  acquisition  planning  activities  rely  upon  this  output  in  order  to  proceed  further  with  the 


Figure  91:  Pre-MS  B  Acquisition  swim  lane  preparations  for  Acquisition  Panels 

Only  upon  completion  of  the  three  cost  estimates,  as  noted  by  the  queue  titled  "for  Affordability 
Assessment  PreB",  is  the  "Affordability  Assessment  PreB"  done.  The  time  duration  for  this  assessment  is 
approximately  120  to  180  days,  with  a  most  likely  value  of  160  days.  The  source  of  this  information  is 
official  documents  and  by  inference.  This  was  validated  by  acquisition  personnel. 

An  artificial  artifact  of  the  model  is  inserted  here  to  check  for  funding,  and  a  penalty  assessed  if 
it  is  not  available.  This  will  be  discussed  later. 

With  the  completed  of  the  acquisition  planning  activities  and  the  system  verification  review 
completed,  both  shown  previously,  the  process  task,  "Draft  RFP  Preparation  PreB"  may  begin.  It  takes 
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10  to  20  days,  with  a  most  likely  value  of  17  days.  Typically  there  is  some  effort  to  waive  the  firm 
prerequisites  and  preliminary  results  will  be  used,  especially  if  trying  to  meet  a  "target"  MS  B  date  goal, 
but  the  model  does  not  attempt  to  account  for  this  variation.  The  source  of  this  information  is 
experience  and  source  documents,  and  was  subsequently  validated  by  acquisition  personnel.  Outputs 
from  this  step  go  to  two  different  tasks  -  one  related  to  the  RFP  coordination  process,  and  another  to 
the  development  of  the  Source  Selection  plans. 

A  process  task  called  "RFP  coordination  process  PreB"  has  a  time  distribution  of  25  to  50  days, 
with  a  most  likely  value  of  45  days.  Some  of  this  coordination  is  done  within  the  branch  of  service  doing 
the  acquisition  and  some  of  it  is  done  with  industry.  The  source  of  this  information  is  interviews, 
experience  and  source  documents.  It  was  later  validated  by  acquisition  personnel. 

Another  process  task,  "source  selection  plans  preB"  has  a  time  distribution  of  30  to  65  days, 
with  a  most  likely  value  of  60  days.  This  time  duration  is  influenced  by  the  current  state  of  the 
contractor's  work  which  impacts  the  final  requirements  that  will  be  part  of  the  future  contracting  effort. 
The  source  of  this  information  is  experience  and  published  timelines.  Validation  was  provided  by 
acquisition  personnel. 

An  artifact  of  the  model  requires  that  the  three  different  parallel  processes  be  brought  back 
together  prior  to  proceeding  further. 

Upon  return  from  the  funding  check,  and  also  as  the  CCD  is  being  finalized  in  the  requirements 
swim  lane,  the  approved  KPPs  will  be  released  to  the  Acquisition  swim  lane.  At  this  point  the  Acquisition 
program  baseline  will  be  set.  This  marks  the  "official"  baseline  for  the  remaining  program  and  will  be 
the  benchmark  against  which  all  further  development  will  be  measured.  It  is  not  unusual  for  these 
attributes  to  be  set  based  on  draft  or  preliminary  documents.  The  task  has  a  time  distribution  of  10  to 
30  days,  with  a  most  likely  value  of  25  days.  The  source  of  this  information  is  official  documents  and 
inference.  It  was  later  validated  by  acquisition  personnel. 
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An  artifact  of  the  model  brings  the  parallel  paths  together  with  the  activity  called  "Complete 


predecessor  activities  preB."  Then  the  model  sends  the  program  down  the  proper  path  depending  upon 
the  ACAT  level  of  the  program.  The  process  task  for  the  preparation  for  the  Acquisition  Panels  has  a 
time  distribution  of  40  to  60  days,  with  a  most  likely  value  of  56  days  for  ACAT  I  programs.  For  the  ACAT 
II  and  ACAT  III  programs,  the  preparation  requires  15  to  30  days,  with  a  most  likely  value  of  25  days.  The 
majority  of  this  time  is  to  get  in  synchronization  with  the  set  calendar  of  these  panels.  Most  of  the 
"work"  has  already  been  done  prior  to  this  time  in  previous  tasks.  The  source  of  this  information  is  an 
interview  and  source  documents.  It  was  later  validated  by  acquisition  personnel. 

The  process  task  entitled  "Acquisition  Panels  PreB"  has  a  time  distribution  of  15  to  35  days,  with 
a  most  likely  value  of  30  days.  The  time  distribution  allows  for  delays  and  resolution  of  last  minute 
issues  in  these  events. 


Figure  92:  Pre-MS  B  PPBE  Funding  check 
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Despite  the  discrete  nature  of  the  model  the  PPBE  is  constantly  seeking  updates  to  the  cost  and 


schedule  updates  for  the  system.  Nevertheless,  for  simplicity,  the  first  formal  input  of  these  costs 
occurs  upon  completion  of  the  "Affordability  Assessment"  in  the  Acquisition  swim  lane.  The  response  of 
the  model  to  this  input  is  a  decision  point  entitled  "Funds  set  aside  for  next  phase  in  FYDP  at  80%  of  ICE 
amount  PreB".  This  decision  point  has  a  probability  of  70%.  This  means  that  the  Air  Force  is  making  an 
investment  decision  into  the  development  of  this  concept.  The  irony  is  that  the  decision  to  fund  at  this 
level  is  made  within  the  corporate  structure  of  the  Air  Force,  e.g.  within  the  Budgeting  and  Programming 
system,  and  the  acquisition  System  with  its  accompanying  Milestone  decision  is  merely  a  ratification  of 
the  previously  taken  action  by  the  Air  Force. 

If  the  decision  is  "no",  a  time  delay  is  incurred.  The  time  delay  task  has  a  time  distribution  of  30 
to  180  days,  with  a  most  likely  value  of  120  days  for  ACAT  I  programs.  For  ACAT  II  and  ACAT  III 
programs,  the  time  distribution  is  90  to  270  days,  with  a  most  likely  value  of  225  days.  The  reason  for 
these  distributions  is  that  significant  resources  have  been  expended  by  the  Air  Force  to  date  and  there  is 
tremendous  institutional  pressure  to  continue  the  development  of  the  concept.  This  does  have  a  direct 
impact  on  reaching  Milestone  B  -  the  program  must  be  fully  funded,  e.g.  at  80%  of  the  ICE  amount,  in 
order  to  proceed  further.  In  reality,  this  means  that  if  the  money  still  isn't  there,  having  the  plan  in 
place  prevents  further  delays,  but  it  still  doesn't  guarantee  the  program  will  be  fully  funded. 
Furthermore,  it  is  also  likely  the  program  is  funded  to  the  Program  Office  Cost  estimate,  which  is 
historically  lower  than  ICE  estimates. 
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Figure  93:  Pre-MS  B  Acquisition  swim  lane  Milestone  B  decision 


Upon  formal  receipt  of  the  approved  CCD  from  the  requirements  swim  lane,  the  milestone 
decision  can  be  made.  A  decision  point  entitled  "MDA  Milestone  Approval  PreB"  has  a  probability  of 
99%.  This  probability  relies  upon  the  confluence  of  all  previous  tasks  preparing  for  the  next  phase  of 
acquisition  development  and  the  approved  CDD  from  the  requirements  swim  lane.  The  source  of  this 
information  is  official  documents  and  subsequent  validation  from  acquisition  personnel. 

If  "no",  a  check  is  made  to  see  if  the  program  has  failed  previously.  If  so,  the  program  is  killed. 

If  not,  a  counter  is  attached  to  the  program  to  indicate  the  milestone  failure.  Officially,  the  process 
returns  to  the  "Preparation  for  Acquisition  Panels"  step  to  repeat  the  entire  process  from  there. 
However,  the  MDA  can  reject  the  program  for  various  reasons  and  the  personnel  working  the  program 
would  go  back  to  the  portions  that  needed  to  be  redone  and  fix  them.  Therefore,  an  artificial  step 
entitled  "Delay  to  repeat  required  steps  PreB,"  was  created.  It  has  a  time  distribution  of  60  to  180  days, 
with  a  most  likely  value  of  120  days.  After  completion  of  this  step,  the  program  then  returns  to  the 
MDA  decision  point.  If  the  program  is  rejected  twice,  the  process  ends,  as  evidenced  with  the  model 
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artifacts  of  "End  Simulation  PreB  4,"  "Record  8,"  and  "Kill  at  MS  B  decision."  In  essence,  this  means  the 


sponsoring  MAJCOM  will  withdraw  its  support  and/or  funding  and/or  restructure  the  program  by  going 
back  to  the  beginning  of  the  overall  process.  If  the  MDA  approves  the  program,  Milestone  "B"  is 
declared.  The  "program"  contains  all  of  the  information,  approval,  and  consent  needed  to  proceed  into 
the  next  phase  of  activity. 


Figure  94:  Pre-MS  B  Acquisition  swim  lane  financial  uncertainty  engine 

Contract  management  is  not  explicitly  modeled.  However,  several  other  activities  are  modeled 
that  can  be  used  a  surrogates  for  this  activity.  The  first  step  in  this  surrogate  activity  mentioned  is  the 
generation  of  a  "Program  Review  Condition."  Depending  upon  the  ACAT  level,  this  activity  would 
generate  a  potential  program  review.  If  the  program  in  question  was  ACAT  I,  the  condition  would  be 
invoked  using  a  triangular  distribution  between  90  and  120  days,  with  a  most  likely  value  of  105  days. 
For  ACAT  II  programs,  this  triangular  distribution  is  between  160  and  200  days,  with  a  most  likely  value 
of  180  days.  For  ACAT  III  programs,  the  triangular  distribution  is  between  160  and  200  days,  with  the 
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most  likely  value  of  200  days.  Originally,  these  distributions  were  longer,  on  the  order  of  about  every  six 


months  to  mimic  the  behavior  of  the  Spring  and  Fall  program  reviews.  Many  of  those  who  helped 
validate  the  model  took  exception  to  this  approach  and  indicated  that  whether  under  a  formal  review  or 
not,  the  frequency  of  these  serious  funding  questions  was  tied  to  the  ACAT  level.  The  Higher  the  ACAT 
level,  the  more  frequent  reviews  are  or  with  a  lower  ACAT  level,  the  less  frequent  the  reviews  are. 
Therefore,  the  ACAT  III  programs  approach  a  nearly  six  month  review  cycle  while  the  ACAT  I  programs 
are  more  frequent. 

A  check  is  made  to  see  if  the  contract  has  started  yet.  If  not,  the  condition  is  "thrown  away"  via 
the  model  artifact  "Dispose  of  program  review  prior  to  need."  Otherwise,  the  program  condition  meets 
a  decision  point  called  "Program  review  OK."  It  has  a  probability  of  95%.  A  future  work  modification 
would  make  this  probability  variable,  as  the  number  of  "unanticipated  events"  increases,  as  discussed 
later,  the  probability  should  slowly  decrease. 

If  the  result  of  the  program  review  is  "yes",  another  decision  point  is  reached  called  "Funds 
Redirected."  This  decision  point  has  a  probability  of  20%.  The  source  of  this  information  is  interviews 
and  inference,  and  later  validation.  This  speaks  to  the  fact  that  even  though  a  program  may  be  doing 
well,  outside  influences  may  have  already  decided  to  make  financial  changes  anyway. 

If  the  outcome  of  the  program  review  is  negative  or  the  outcome  of  the  "funds  redirected"  point 
is  "yes",  then  the  process  is  directed  to  a  task  called  "Prepare  Courses  of  Action,"  which  will  be 
discussed  later.  A  negative  outcome  from  the  "funds  redirected"  step  will  end  the  condition  with  the 
model  artifact  "End  of  Program  Review  Loop." 
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Figure  95:  Pre-MS  B  Contractor  swim  lane  uncertainty  generator  and  contract  engine 

The  contractor  portion  of  the  model  is  significantly  less  complex  than  the  other  portions  of  the 
model.  However,  this  part  of  the  model  captures  an  important  interaction  that  can  serve  as  one 
surrogate  for  uncertainty.  This  surrogate  is  easily  recognizable  and  often  mentioned  in  the  literature  as 
"stuff  happens".  The  abstractions  in  this  swim  lane  will  still  keep  this  surrogate  viable,  but  won't  cause 
it  to  be  too  complex  for  understanding.  The  first  task  is  to  generate  an  uncertainty  event.  This  occurs 
on  a  frequency  modeled  by  a  triangular  distribution  with  a  range  between  30  and  90  days,  with  a  most 
likely  value  of  60  days.  During  the  validation  of  the  model,  acquisition  professionals  pointed  out  that  the 
kinds  of  things  that  required  their  attention  outside  of  their  normal  job  descriptions  relating  to  the 
program  in  development  happened  about  every  two  months. 

The  check  point  "Event  Happens  preB"  waits  for  the  contract  to  start.  If  the  contract  has  not 
started,  the  uncertainty  event  is  thrown  away,  as  evidenced  by  the  model  artifact  "Dispose  of  event 
happens  prior  to  need."  If  it  has  started,  the  event  proceeds  to  the  next  step,  e.g.  an  "event"  has 
happened.  These  are  the  larger  issues  that  arise  during  the  day-to-day  performance  of  the  contract. 
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This  task  serves  largely  as  the  surrogate  for  uncertainty.  The  source  of  this  information  is  experience 


and  the  assumptions  required  for  this  model  to  work. 

A  decision  point  called  "Scope  Growth/Technical  Problems?"  has  a  probability  of  20%.  The 
smaller  probability  is  a  trade-off  between  the  short  time  duration  of  the  previous  step  and  the 
probability  that  troubles  really  do  occur  over  the  course  of  a  contract.  If  "yes",  the  flow  is  split,  so  that 
one  "event"  moves  to  a  process  step  in  the  Acquisition  Swim  Lane,  "Prepare  Courses  of  Action,"  which 
will  be  discussed  later.  Additionally,  the  process  flows  in  the  direction  of  another  decision  point,  called 
"Contract  Complete?"  The  source  of  this  information  is  experience  and  is  required  to  make  the  model 
work. 

First,  a  check  is  made  to  see  if  the  program  is  ACAT  I  or  not.  If  the  program  is  ACAT  I,  the 
decision  point,  "Begin  Testing  PreB"  is  met.  If  75%  of  the  original  contract  time  has  elapsed  since  the 
contract  start,  a  signal  will  be  set  "Declaring  start  of  T&E  preB".  Otherwise,  the  event  proceeds  to  the 
next  step.  If  the  program  is  ACAT  II  or  ACAT  III,  the  decision  point  "Begin  Testing  ACAT  II  or  III  PreB"  is 
met.  If  85%  of  the  original  contract  time  has  elapsed  since  the  contract  start,  a  signal  will  be  set 
"Declaring  start  of  T&E  preB."  Otherwise,  the  event  proceeds  to  the  next  step. 

The  next  decision  point  is  to  query  if  the  contract  length  is  within  6  months  of  contract 
completion.  If  "yes",  the  next  step  is  to  query  if  it  is  the  first  time.  If  "yes",  then  this  triggers  the 
Acquisition  Planning  Activity  step  and  the  three  costing  activities.  It  also  sets  a  flag  indicating  it  has 
tripped  the  contractor  loop  so  subsequent  events  won't  go  down  this  path  again  and  then  proceeds  to 
the  next  step.  If  the  event  is  met  with  "no"  to  either  question,  the  flow  proceeds  to  the  next  step  as 
well. 

The  decision  point  "Contract  Complete  preB"  is  a  simple  logic  test  to  see  if  the  total  time 
elapsed  is  greater  than  total  of  the  contract  starting  time  and  the  contract  length.  If  "no",  the  event  is 
removed  from  the  model  using  the  artifact,  "End  of  Event  Happens  Loop  PreB."  If  "yes",  a  query  is  made 
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to  see  if  this  is  the  first  time  the  event  has  arrived  at  this  point.  If  the  query  is  affirmative,  the  final 
variable  for  the  future  work  extension  on  the  final  contract  cost,  which  will  be  explained  later,  is  set. 
Then  the  event  is  disposed  at  the  "Completion  of  contract  PreB."  If  the  query  is  false,  is  it  immediately 
sent  also  to  the  artifact  "Completion  of  contract  PreB"  for  disposal. 

This  particular  approach  was  used  to  accommodate  multiple  "events"  working  their  way 
through  the  system  at  any  given  time  and  be  able  to  trigger  events  appropriately. 


Figure  96:  Pre-MS  B  Acquisition  swim  lane  program  management  and  oversight  loop 

This  particular  set  of  activities  drew  the  most  scrutiny  during  the  validation  portion  of  the  model 
development,  especially  from  the  acquisition  personnel.  Many  changes  were  made  to  the  model  based 
upon  their  feedback. 

Whether  an  "event"  or  a  "program  review  condition"  appears  at  the  step,  "Prepare  Courses  of 
Action  PreB,"  it  is  treated  the  same.  The  task,  "Prepare  Courses  of  Action  PreB"  has  a  time  distribution 
of  5  to  10  days,  with  a  most  likely  value  of  8  days.  This  gets  into  the  daily  activities  of  the  office 
managing  the  program  and  dealing  with  issues.  The  source  of  this  information  is  personal  experience, 
interviews  and  inference.  Acquisition  personnel  validated  the  information  at  this  step. 

At  this  point,  80%  of  the  process  flow  will  proceed  down  the  "Scope  Growth/Technical 
problems"  path.  The  other  20%  will  follow  the  "Funding  Problem"  path.  The  source  of  this  information 
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is  from  interviews,  inference  and  personal  experience.  Regardless  of  the  reason,  since  scope  growth 


and  technical  issues  can  also  be  boiled  down  to  financial  impacts,  the  rest  of  the  diagram  deals  with 
financial  issues. 

A  decision  point,  "Funding  problem  Contract  Change  Required  PreB"  has  a  probability  of  40%.  A 
future  work  extension  to  the  model  to  make  it  more  realistic  would  be  to  allow  this  probability  to  slowly 
increase  depending  upon  the  total  number  of  "events"  that  have  happened.  If  "false",  the  event  or 
program  review  condition  is  disposed  at  the  model  artifact  "End  of  contract  change  path."  If  "true," 
several  quality  values  are  set.  These  quality  values  will  determine  the  percentage  of  cost  and  schedule 
growth  added  in  a  later  step. 

The  decision  point  named  "Seek  Funds  PreB"  has  a  probability  of  30%.  This  probability  is 
influenced  by  whether  or  not  the  program  can  deal  with  the  event  or  problem  on  its  own.  The  reason 
for  the  "problem"  may  be  outside  of  the  acquisition  swim  lane.  If  "yes",  a  task  entitled  "PEM  or  other 
staff  find  money  PreB"  begins.  It  has  a  time  duration  of  14  days  to  180  days  for  ACAT  I  programs,  with  a 
most  likely  value  of  83  days.  For  ACAT  II  and  ACAT  III  programs,  there  is  a  longer  timeline  associated 
with  finding  funds,  having  the  same  distribution,  but  the  most  likely  value  is  160  days.  This  time 
duration  is  influenced  by  the  fact  that  there  are  many,  many  sources  of  money.  These  sources  can  be 
other  programs,  results  of  different  "periodic  reviews"  and  other  items.  Sometimes,  the  movement  of 
money  must  rely  upon  approval  from  higher  levels,  up  to  and  including  Congress.  Additionally,  the 
timing  of  when  the  request  goes  in,  e.g.  the  month  of  the  year  compared  to  the  POM  cycle  and  the 
overall  amount  required,  affects  the  ability  of  the  PEM  to  find  the  money  required,  e.g.  the  more  money 
requested,  the  longer  amount  of  time  is  necessary  to  obtain  it.  This  step  was  validated  by  PPBE  and 
acquisition  personnel. 

As  an  aside,  in  the  case  of  budget  execution  problems,  another  task  is  invoked  but  it  is  not 
represented  in  the  model.  It  is  called  "Prepare  Program  budget  decision  information."  This  task  feeds 
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directly  into  the  budgeting  and  programming  process.  It  is  used  in  subsequent  iterations  of  the  PPBE 


process.  The  source  of  this  information  is  official  documentation  and  inference. 

A  decision  point  entitled,  "Obtain  funds  in  a  timely  manner  PreB"  has  a  probability  of  65%.  This 
probability  is  influenced  by  the  fact  that  there  are  many,  many  sources  of  money.  These  sources  can  be 
other  programs,  results  of  different  "periodic  reviews"  and  other  items.  Sometimes  having  the  money 
arrive  "late"  is  just  as  bad  as  or  worse  than  not  getting  the  money  at  all  due  to  the  various  funding 
constraints  associated  with  the  funds.  The  source  of  this  information  is  inference  and  experience.  If 
true,  e.g.  moneys  are  obtained  in  a  timely  manner,  the  impact  will  be  a  4.5%  growth  in  the  cost  and 
schedule  of  the  program.  If  false,  e.g.  moneys  are  not  obtained  in  a  timely  manner,  the  impact  will  be  a 
5.5%  growth  in  the  cost  and  schedule  of  the  program.  These  penalties  will  be  assessed  in  a  later  step. 

A  process  task,  "Change  contract/re-scope  effort"  has  a  time  distribution  of  15  to  60  days,  with  a 
most  likely  value  of  20  days,  where  the  variation  is  dependent  upon  the  scale  of  contract  change  and  the 
complexity  of  the  change.  This  is  associated  with  the  actual  time  required  to  process  a  contract  change. 
The  source  of  this  information  is  experience  and  inference. 

Appendix  A  provides  some  insights  into  the  various  causes  of  cost  and  schedule  growth, 
enumerated  through  an  extensive  literature  search.  In  some  sense,  the  randomness  of  the  outcomes  is 
dependent  upon  where  in  the  system  the  activity  occurs.  For  purposes  of  simplicity,  an  assumption  that 
with  every  contract  change,  a  5%  schedule  and  cost  penalty  should  be  assessed,  is  made.  This 
approximation  was  validated  as  reasonable  by  acquisition  personnel. 

The  step  "Set  cost  and  schedule  penalties"  is  where  an  adjustment  to  the  program  is  made; 
reflected  in  terms  of  cost  and  schedule65.  The  degree  to  which  both  cost  and  schedule  will  be  changed  is 
dependent  upon  the  quality  variables  set.  Cost  and  schedule  will  either  experience  a  4.5%,  a  5%,  or  a 

65  Since  it  has  already  been  noted  that  schedule  is  a  reasonable  surrogate  for  cost  or  rather,  is  closely  tied  to  cost, 
the  model  only  closely  tracks  schedule.  The  "hooks"  are  there  for  future  work  to  add  cost  as  an  explicit  part  of  the 
model. 
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5.5%  growth  to  their  current  baseline  status.  As  multiple  issues  can  be  working  their  way  through  the 


system  at  any  given  time,  there  is  a  potential  for  large  cost  and  schedule  growth  to  occur. 

Following  this  activity,  the  "event"  or  "program  review  condition"  is  permanently  removed  from 
the  model  through  the  model  artifact  of  "End  of  Program  Management  and  Oversight  loop." 

The  Pre-Milestone  C  Swim  Lanes 

This  phase  represents  all  of  the  Pre-MS  C  activities  in  all  four  swim  lanes:  Requirements;  PPBE; 
acquisition;  and  contractors.  The  notations  on  the  figure  below  indicate  which  figure  to  refer  to  in  order 
to  get  detailed  model  information  on  specific  sections  of  the  model.  The  detailed  explanation  for  the 
content  within  the  figure  will  immediately  follow  the  figure. 


Figure  97:  Pre-MS  C  Swim  Lanes  with  Reference  Figures 

This  phase  begins  in  the  requirements  swim  lane,  in  the  upper  left  corner  of  this  figure. 
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allow  parallel  processing  in  the  requirements  swim  lane  and  the  acquisition  swim  lane.  The  next  step  is 
"Wait  for  Signal  from  Acquisition  PreC."  This  step  is  important  as  it  serves  as  a  time  delay,  waiting  for 
the  acquisition  system  to  award  a  contract.  After  the  contract  is  awarded,  the  other  activities  of  the 
swim  lane  may  begin.  For  practical  purposes,  this  merely  acknowledges  the  need  for  the  requirements 
system  to  ascertain  the  direction  of  the  program  in  development. 

The  first  process  task  of  this  swim  lane  is  entitled  "Prepare  Concept  of  Operation"  with  a  time 
distribution  ranging  from  the  amount  of  time  equal  to  60%  of  the  System  Design  and  Development 
original  contract  length  to  80%  of  the  System  Design  and  Development  original  contract  length,  with  the 
most  likely  amount  being  70%  of  the  System  Design  and  Development  original  contract  length.  The  task 
starts  at  roughly  the  same  time  the  contract  is  awarded.  The  inputs  to  this  task  are  the  outputs  from  the 
previous  phase.  The  source  for  this  information  is  from  interviews  and  was  validated  by  JCIDS 
participant. 

At  the  Milestone  B  decision,  the  MDA  may  also  direct  another  AOA  to  be  conducted  to  update 
or  correct  the  previous  AOA  results,  taking  into  account  any  factors  that  may  have  changed  during  the 
preceding  phase.  The  probability  of  this  occurring  is  unknown  at  this  time,  however,  for  purposes  of  this 
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model,  the  time  to  complete  the  AOA  is  less  than  the  "Prepare  Concept  of  Operation"  task  and  is 
therefore  inconsequential  to  the  overall  task.  Any  results  of  the  AOA  will  be  folded  into  this  activity. 

During  the  duration  of  this  task,  information  about  future  capabilities  is  sent  to  Acquisition  and 
the  Budgeting  swim  lanes  to  eventually  get  added  to  this  program.  There  is  a  lot  of  interaction  during 
this  time  with  Acquisition,  especially  in  attempting  to  understand  how,  when,  and  where  this  program's 
capabilities  can  be  used.  The  process  will  attempt  to  wait  as  long  as  possible  for  more  detailed  results 
from  prototypes,  engineering  models  and  other  acquisition  results.  The  source  for  this  information  is 
from  experience  and  interviews. 

A  decision  point  entitled  "decision  to  pursue  requirements"  has  a  probability  of  98%.  The 
ultimate  purpose  of  starting  this  process  is  to  result  in  an  approved  Capability  Production  Document, 
CPD.  The  reason  for  the  high  probability  is  that  the  MDA  has  an  agreement  with  the  MAJCOM- 
sponsoring  commander  to  pursue  Milestone  C  and  Acquisition  activity  is  already  taking  place.  The 
organizational  momentum  is  difficult  to  stop.  The  source  of  this  information  is  by  inference  and 
documented  materials.  If  "no",  a  decision  point  entitled,  "check  on  conditions  Pre  C,"  is  met  to  see  if 
this  program  has  been  turned  down  twice.  If  "no,"  then  a  decision  variable  will  be  set.  Next,  a  process 
task  entitled  "wait  for  more  favorable  conditions  PreC"  is  seen.  The  time  distribution  is  100  to  150  days, 
with  a  most  likely  value  of  115  days.  This  is  to  give  the  acquisition  system  more  time  to  develop  and 
mature  the  program  further  before  making  another  decision.  If  the  decision  is  "no"  a  second  time,  the 
program  trips  the  "check  on  conditions  PreC"  decision  point  and  it  is  killed  via  the  model  artifacts 
"Record  11,"  "end  simulation  PreC,"  and  "End  Prior  to  start  of  Requirements  swim  lane  preC"  (not 
shown).  This  is  all  placed  into  an  archive  to  be  revisited  later  by  the  enterprise  system. 
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Figure  99:  Pre-MS  C  Entry  into  formal  requirements  process  at  MAJCOM 

A  task  entitled  "draft  briefing  and  materials  PreC"  has  a  time  distribution  of  10  days  to  40  days, 
with  a  most  likely  value  of  31.  The  source  of  this  information  was  derived  from  interview  data  and 
validated  byJCIDS  participant. 

A  decision  point  entitled  "MAJCOM  A  Letters  Coordinate  and  Concur  PreC"  has  a  probability  of 
90%.  The  source  of  this  information  is  interview  and  later  validation  by  JCIDS  participant.  Assuming  this 
was  a  first  time  rejection  by  the  MAJCOM  "A"  Letters,  the  program  proceeds  to  a  "Check  Condition 
PreC"  step  which  is  a  model  artifact  checking  for  a  failure  flag,  it  then  meets  the  model  artifact  entitled 
"Add  counter  through  feedback  path  PreC,"  which  sets  a  variable  indicating  a  failure.  The  probability  of 
the  next  step,  a  decision  point  titled,  "decision  to  repursue  PreC,"  is  approximately  85%.  If  successful, 
the  next  step  is  back  toward  the  MAJCOM  "A"  letters,  through  the  task  "Update  Briefing  Materials 
PreC."  This  task  has  a  time  distribution  of  10  to  40  days,  with  a  most  likely  value  of  35  days.  If  not,  the 
item  is  killed  and  archived,  with  the  model  artifacts  "Record  13,"  "End  Simulation  PreC,"  and  "End  prior 
to  start  of  Requirements  swim  lane  PreC." 
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Figure  100:  Pre-MS  C  Requirements  swim  lane  MAJCOM  process 

A  task  entitled  "Update  and  schedule  calendar  PreC"  has  a  time  distribution  of  3  to  15  days,  with 
a  most  likely  value  of  12  days.  The  source  of  this  information  is  inference  derived  from  interview  data 
and  was  validated  by  JCIDS  participant. 

A  decision  point  entitled  "Pre-RSR  MAJCOM  A8  PreC"  has  a  probability  of  99%.  If  "false,"  then 
the  program  proceeds  to  the  "check  condition"  step  as  discussed  with  Figure  99.  The  source  of  this 
information  is  interview  and  was  validated  by  JCIDS  participant. 

A  task  entitled  "Finalize  RSR  and  calendar  items  PreC"  has  a  time  distribution  of  21  to  35  days, 
with  a  most  likely  value  of  28  days.  The  source  of  this  information  is  from  an  interview  and  validated  by 
JCIDS  participant  and  the  official  Document  Timeline  Calculator. 

A  decision  point  entitled  "RSR  HQ  USAF  A5R  PreC"  has  a  probability  of  98%.  The  source  of  this 
information  is  an  interview.  If  the  answer  to  this  decision  point  is  "no",  the  process  returns  to  the 
originator  via  the  "check  condition"  step.  The  RSR  must  include  the  funding  strategy  for  the  remaining 
phases  of  Acquisition.  If  the  Joint  Potential  Designator  needs  to  be  updated,  it  is  done  at  this  point. 
However,  the  model  assumes  nothing  changes.  ACAT  I  activities  have  a  100%  chance  of  getting  joint 
interest.  ACAT  II  activities  are  usually  designated  as  "joint  information"  and  any  comments  are  taken 
under  advisement,  while  ACAT  III  activities  are  designated  "independent"  AF  only  and  are  distributed  to 
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the  other  services  as  a  courtesy  only  for  comment  and  review.  The  joint  information  was  validated  by 


A5  personnel  and  the  official  Document  Timeline  Calculator. 


Figure  101:  Pre-MS  C  Requirements  swim  lane  JCIDS  process 

Returning  to  the  process  flow,  the  next  task  is  called  "form  high  performance  team  preC"  has  a 
time  distribution  of  30  to  45  days,  with  a  most  likely  value  of  41  days.  The  source  of  this  information  is 
an  interview  and  validated  by  JCIDS  participant  and  the  official  Document  Timeline  Calculator. 

The  task  called  "High-Performance  Team  (HPT)  work  PreC"  has  a  time  distribution  of  5  to  7  days, 
with  a  most  likely  value  of  6  days.  The  source  of  this  information  is  an  interview  and  later  validated  by 
JCIDS  participant.  The  product  of  this  event  is  a  "draft  document". 

At  this  point  a  variable  is  set,  "Release  KPPs  to  Acquisition  preC,"  in  order  to  trigger  some 
process  work  in  the  acquisition  swim  lane.  This  is  an  artifact  of  the  model,  but  was  discussed  as  an 
important  issue  during  the  validation  activity  in  discussions  with  JCIDS  participants  and  acquisition 
personnel. 

At  this  point,  a  decision  point  entitled  "Determine  document  approval  path  preC"  separates  the 
activity  into  three  separate  paths  to  approval  depending  upon  the  Joint  Potential  Designator,  e.g.  a 
"rough"  surrogate  for  the  ACAT  level,  of  the  activity.  The  model  separates  these  based  on  the  previously 
designated  ACAT  level.  ACAT  I  programs  go  to  the  "Joint  Interest  preC"  step.  ACAT  II  programs  go  to  the 
"Joint  Integration  preC"  step  and  ACAT  III  programs  go  to  the  "Independent  Document  preC"  step. 
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Following  the  completion  of  these  steps,  which  will  be  discussed  in  detail  shortly,  the  CPD 


completion  time  is  recorded  as  an  artifact  of  the  model  with  the  step,  "Record  CPD." 


The  task  called  "Draft  document  Indep  preC"  has  a  time  distribution  of  30  to  60  days,  with  a 
most  likely  value  of  55  days  and  is  really  an  "advanced"  draft  of  the  document  previously  worked  on  by 
the  High  Performance  team.  This  is  the  time  for  internal  coordination  and  clean-up.  Details  from  the 
draft  document  are  sent  to  Acquisition  to  jumpstart  the  Acquisition  planning  activities.  The  source  of 
this  information  is  an  interview  and  validated  by  JCIDS  participants  as  well  as  by  the  official  Document 
Timeline  Calculator.  In  reality,  at  this  point,  information  is  passed  to  the  acquisition  system  for 
preparatory  work. 

However,  before  the  next  step  may  begin,  the  Acquisition  swim  lane  must  report  a  successful 
Design  Readiness  Review  (DRR).  The  process  task  "Wait  for  Successful  Design  Readiness  Review  Indep 
PreC"  is  a  queue  waiting  for  that  signal.  This  information  obtained  and  validated  by  JCIDS  participant. 

The  task  called  "air  staff  processes  indep  preC"  has  a  time  distribution  of  21  to  42  days,  with  a 
most  likely  value  of  29  days.  The  source  of  this  information  is  interview  and  official  documentation.  A 
few  days  of  internal  processing  time  and  a  maximum  21-day  review,  with  the  possibility  of  an  extension, 
form  the  basis  of  the  time  distribution.  The  information  was  later  validated  by  a  JCIDS  participant  and 
the  official  Document  Timeline  Calculator. 
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The  decision  point  entitled  "Critical  comments  Indep  PreC"  has  a  probability  of  95%.  The  source 


of  this  information  is  an  interview  and  validated  by  JCIDS  participant.  If  there  are  no  critical  comments, 
the  task  proceeds  to  the  AFROC  Preparations  step. 

The  task  called  "comment  resolution  indep  preC"  has  a  time  distribution  of  15  to  45  days,  with  a 
most  likely  value  of  45  days.  This  is  where  the  sponsor  resolves  0-666  level  comments.  The  source  of 
this  information  is  interview  and  validation  by  JCID  participant  and  the  official  Document  Timeline 
Calculator. 

The  decision  point  entitled  "MAJCOM  approval  indep  preC"  has  a  probability  of  99%.  The 
source  of  this  information  is  interview  and  later  validation  by  JCIDS  participant.  If  the  answer  is  no,  the 
next  step  remains  comment  resolution  and  information  is  passed  into  the  budgeting  and  programming 
system  to  deal  with  the  financial  ramifications.  Usually,  this  means  the  activity  is  put  on  "hold"  for  a 
year,  probably  the  result  of  some  "critical  comments"  that  were  not  immediately  resolved.  This  is 
represented  by  the  step,  "Hold  for  a  year  later  in  process  Indep  preC."  It  has  a  time  distribution  of  270 
to  365  days,  with  a  most  likely  value  of  300  days.  If  the  answer  is  yes,  the  activity  proceeds  to  the  next 
step. 

The  task  called  "AFROC  preparations  Indep  preC"  has  a  time  distribution  of  30  to  60  days,  with  a 
most  likely  value  of  45  days.  The  source  of  this  information  is  an  interview  and  the  official  Document 
Timeline  Calculator. 

The  decision  point  "AFROC  decision  indep  preC"  has  a  probability  of  90%.  Of  those  90%,  20%  to 
30%  will  have  "actions"  (Post  AFROC  "Go-do"  actions)  to  accomplish,  see  step  "Post  AFROC  actions 
Indep  preC"  and  must  return  to  the  AFROC  within  0  to  15  days,  with  a  most  likely  value  of  11  days.  The 
source  is  the  official  Document  Timeline  Calculator. 


0-6:  refers  to  a  Colonel  or  Captain  (for  the  Navy). 


339 


If  the  initial  answer  at  the  AFROC  is  "no,"  there  is  a  99%  chance  the  activity  is  "dead"  and  the 


document  is  archived.  First,  there  is  a  check  to  see  if  the  rejection  is  the  first  time  or  not.  This  is  done  at 
the  step  entitled,  "Check  for  previous  path  indep  PreC."  The  model  sets  a  variable  in  "Set  tracking  Indep 
PreC."  The  next  step  is  "Dead  activity  Indep  PreC."  This  step  has  a  probability  of  99%  to  kill  the 
program.  If  not,  the  program  goes  back  to  the  step  "comment  resolution  Indep  PreC."  During 
validation,  the  source  indicated  he  had  never  seen  anything  go  back  through  the  AFROC  a  2nd  time 
based  on  his  25+  years  of  experience.  Therefore,  the  path  taken  by  the  less  than  likely  1%  of  documents 
would  be  back  to  the  MAJCOM  for  approval  through  the  comment  resolution  process  and  follow  the 
normal  process  beyond  that.  Otherwise,  the  activity  is  "dead"  and  this  is  represented  by  the  model 
artifacts  "End  Simulation  PreC  1,"  "Record  26,"  and  "Death  at  AFROC  Indep  PreC."  The  source  of  this 
information  is  an  interview  as  well  as  review  of  official  process  documents.  It  has  been  validated  by  a 
JCIDS  participant. 

At  this  point  the  CPD  is  approved  and  the  program  resumes  the  process  flow  as  depicted  in 
Figure  101. 


Figure  103:  Pre-MS  C  Requirements  swim  lane  Joint  Integration  process.  Part  I 

The  task  called  "draft  document  joint  integ  preC"  has  a  time  distribution  of  30  to  60  days,  with  a 
most  likely  value  of  55  days.  This  is  really  an  "advanced"  draft  of  the  document  previously  worked  on  by 
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the  High  Performance  team.  It  is  the  time  for  internal  coordination  and  clean-up.  The  source  of  this 
information  is  an  interview  and  validated  by  JCIDS  participant  as  well  as  by  the  official  Document 
Timeline  Calculator.  In  reality,  information  is  passed  to  the  acquisition  system  for  preparatory  work. 

However,  before  the  next  step  may  begin,  the  Acquisition  swim  lane  must  report  a  successful 
Design  Readiness  Review  (DRR).  The  process  task  "Wait  for  Successful  Design  Readiness  Review  Interest 
PreC"  is  a  queue  waiting  for  that  signal.  This  information  obtained  and  validated  by  JCIDS  participant. 

The  task  called  "air  staff  processes  joint  integ  preC"  has  a  time  distribution  of  21  to  42  days  with 
a  most  likely  value  of  29  days.  The  source  of  this  information  is  interview  and  official  documentation.  A 
few  days  of  internal  processing  time  and  a  maximum  21-day  review,  with  the  possibility  of  an  extension, 
form  the  basis  of  the  time  distribution.  The  source  of  this  information  was  validated  by  JCIDS  participant 
and  the  official  Document  Timeline  Calculator. 

The  decision  point  entitled  "Critical  comments  joint  integ  preC"  has  a  probability  of  95%.  The 
source  of  this  information  is  an  interview  and  validated  by  JCIDS  participant.  If  there  are  no  critical 
comments,  the  task  proceeds  to  the  "Document  review  phase  joint  integ  preC." 

The  task  called  "comment  resolution  joint  integ  preC"  has  a  time  distribution  of  15  to  45  days, 
with  a  most  likely  value  of  30  days.  This  is  where  the  sponsor  resolves  0-6  level  comments.  The  source 
of  this  information  is  interview  and  validation  by  JCIDS  participant  and  the  official  Document  Timeline 
Calculator. 

The  decision  point  entitled  "MAJCOM  approval  joint  integ  preC"  has  a  probability  of  99%.  The 
source  of  this  information  is  interview  and  later  validation  by  JCIDS  participant.  If  the  answer  is  no,  the 
next  step  remains  comment  resolution  and  information  is  passed  into  the  budgeting  and  programming 
system  to  deal  with  the  financial  ramifications.  Usually,  this  means  the  activity  is  put  on  "hold"  for  a 
year,  probably  the  result  of  some  "critical  comments"  that  were  not  immediately  resolved.  This  step  is 
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entitled  "Hold  for  a  year  later  in  process  joint  integ  preC"  with  a  time  distribution  of  270  to  365  days, 


with  a  most  likely  value  of  300  days.  If  the  answer  is  yes,  the  activity  proceeds  to  the  next  step. 

The  step  "Document  review  phase  joint  integ  preC"  is  applicable  to  50%  of  the  documents 
seeking  approval.  The  other  50%  proceed  directly  to  the  Interoperability  Certification  step.  The  next 
step,  for  those  that  require  it,  is  called  the  "Document  Review  Phase  2  Flag  level  joint  integ  preC".  This 
activity  is  taking  place  because  there  were  "critical  comments"  that  were  not  resolved  during  the  initial 
round  and  the  MAJCOM  sponsor  determined  to  press  ahead  anyway.  This  step  has  a  time  distribution 
of  21  to  42  days,  with  a  most  likely  value  of  34  days.  This  has  been  validated  by  the  Official  Document 
Timeline  Calculator. 

The  next  step  is  another  round  of  the  sponsor  "Resolving  Flag  Level  Comments  joint  integ  preC." 
The  time  distribution  is  15  to  30  days,  with  a  most  likely  value  of  28  days.  This  was  validated  by  the 
official  Document  Timeline  Calculator. 


Figure  104:  Pre-MS  C  Requirements  swim  lane  Joint  Integration  process,  Part  II 

The  decision  point  entitled  "MAJCOM  approval  joint  integ  preC"  has  a  probability  of  99%.  The 
source  of  this  information  is  interview  and  later  validation  by  JCIDS  participant.  If  the  answer  is  no,  the 
next  step  remains  comment  resolution  and  information  is  passed  into  the  budgeting  and  programming 
system  to  deal  with  the  financial  ramifications.  Usually,  this  means  the  activity  is  put  on  "hold"  for  a 
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year,  probably  the  result  of  some  "critical  comments"  that  were  not  immediately  resolved.  This  step  is 
titled  "Hold  for  a  year  later  in  process  2nd  time  joint  integ  preC."  This  step  has  a  time  distribution  of  270 
to  300  days,  with  a  most  likely  value  of  300  days.  If  the  answer  is  yes,  the  activity  proceeds  to  the  next 
step.  This  step  was  validated  by  the  official  Document  Timeline  Calculator. 

The  step  called  "Interoperability  Certification  joint  integ  preC"  has  a  time  distribution  of  10  to  20 
days,  with  a  most  likely  value  of  15  days.  The  validation  came  from  the  official  Document  Timeline 
Calculator. 

The  task  called  "AFROC  preparations  joint  integ  preC"  has  a  time  distribution  of  30  to  60  days, 
with  a  most  likely  value  of  45  days.  The  source  of  this  information  is  an  interview  and  the  official 
Document  Timeline  Calculator. 

The  decision  point  "AFROC  decision  joint  integ  preC"  has  a  probability  of  90%.  Of  those  90%, 
20%  to  30%  will  have  "actions"  (Post  AFROC  "Go-do"  actions)  to  accomplish.  This  possibility  is  called 
"Post  AFROC  actions  joint  integ  preC."  The  step  "Accomplish  Post  AFROC  actions  joint  integ  preC" 
includes  returning  to  the  AFROC  within  0  to  15  days,  with  a  most  likely  value  of  11  days.  If  the  initial 
answer  at  the  AFROC  decision  is  "no,"  there  is  a  99%  chance  the  activity  is  "dead"  and  the  document  is 
archived.  During  validation  of  the  model,  the  source  indicated  he  had  never  seen  anything  go  back 
through  the  AFROC  a  2nd  time  based  on  his  25+  years  of  experience.  The  path  taken  by  the  less  than 
likely  1%  of  documents  would  be  back  to  the  MAJCOM  for  approval  through  the  comment  resolution 
process  and  follow  the  normal  process  beyond  that.  For  the  logic  of  the  model  to  remain  intact,  the 
program  is  first  checked  to  see  if  it  has  previously  been  rejected.  If  not,  a  variable  is  set.  Then  it  meets 
the  step  "Dead  activity  joint  integ  preC"  with  a  99%  probability  of  being  killed  outright.  If  not,  it  is  then 
set  back  to  the  comment  resolution  step.  Otherwise,  the  program  is  killed  via  the  model  artifacts  "End 
Simulation  preC  2,"  "Record  25,"  and  "Death  at  AFROC  joint  integ  preC."  The  source  of  this  information 
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is  an  interview,  the  official  Document  Timeline  Calculator  as  well  as  review  of  official  process 
documents.  It  has  been  validated  by  JCIDS  participant. 

The  step  "Document  signing  and  validation  joint  integ  preC"  is  because  the  AFROC  then  requires 
14  to  30  days,  with  a  most  likely  value  of  26  days,  to  get  the  document  signed  and  validated  across  the 
AF  structure.  The  step  "Final  AFROC  approval  joint  integ  preC"  has  a  99%  chance  to  be  approved  by  the 
AFROC  without  issues.  The  remaining  1%  have  issues  requiring  resolution,  e.g.  step  "Final  AFROC 
resolution  joint  integ  preC,"  typically  requiring  42  to  60  days  to  resolve,  with  a  most  likely  value  of  48 
days. 

At  this  point  the  CPD  is  approved  and  re-enters  the  process  flow  as  depicted  in  Figure  101. 


Figure  105:  Pre-MS  C  Requirements  swim  lane  Joint  Interest  process.  Part  I 

The  task  called  "draft  document  preC  joint  interest"  has  a  time  distribution  of  30  to  60  days, 
with  a  most  likely  value  of  55  days.  It  is  really  an  "advanced"  draft  of  the  document  previously  worked 
on  by  the  High  Performance  team.  This  is  the  time  for  internal  coordination  and  clean-up.  The  source  of 
this  information  is  an  interview  and  validated  by  JCIDS  participant  as  well  as  by  the  official  Document 
Timeline  Calculator.  Information  is  also  passed  to  the  acquisition  system  for  preparatory  work,  but  is 
not  done  explicitly  in  this  model. 
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However,  before  the  next  step  may  begin,  the  Acquisition  swim  lane  must  report  a  successful 


Design  Readiness  Review  (DRR).  The  process  task  "Wait  for  Successful  Design  Readiness  Review  Joint 
PreC"  is  a  queue  waiting  for  that  signal.  This  information  obtained  and  validated  by  JCIDS  participant. 

The  task  called  "air  staff  processes  joint  int  preC"  has  a  time  distribution  of  21  to  42  days,  with  a 
most  likely  value  of  25  days.  The  source  of  this  information  is  interview  and  official  documentation.  A 
few  days  of  internal  processing  time  and  a  maximum  21-day  review,  with  the  possibility  of  an  extension, 
form  the  basis  of  the  time  distribution.  The  source  of  this  information  was  validated  by  JCIDS  participant 
and  the  official  Document  Timeline  Calculator. 

The  decision  point  entitled  "critical  comments?  Joint  int  preC"  has  a  probability  of  95%.  The 
source  of  this  information  is  an  interview  and  validated  by  JCIDS  participant.  If  there  are  no  critical 
comments,  the  task  proceeds  to  the  AFROC  Preparations  step. 

The  task  called  "Comment  resolution  joint  int  preC"  has  a  time  distribution  of  15  to  45  days, 
with  a  most  likely  value  of  30  days.  This  is  where  the  sponsor  resolves  0-6  level  comments.  The  source 
of  this  information  is  interview  and  validation  by  JCIDS  participant  and  the  official  Document  Timeline 
Calculator. 

The  decision  point  entitled  "MAJCOM  approval?  Joint  int  preC"  has  a  probability  of  99%.  The 
source  of  this  information  is  interview  and  later  validation  by  JCIDS  participant.  If  the  answer  is  "no," 
the  next  step  remains  comment  resolution  and  information  is  passed  into  the  budgeting  and 
programming  system  to  deal  with  the  financial  ramifications.  Usually,  this  means  the  activity  is  put  on 
"hold"  for  a  year,  probably  the  result  of  some  "critical  comments"  that  were  not  immediately  resolved. 
This  is  represented  by  the  step  "hold  for  a  year  PreC"  with  a  time  distribution  of  270  to  365  days,  with  a 
most  likely  value  of  300  days.  If  the  answer  is  yes,  the  activity  proceeds  to  the  next  step. 
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The  task  called  "AFROC  preparations  joint  int  preC"  has  a  time  distribution  of  30  to  60  days,  with 


a  most  likely  value  of  45  days.  The  source  of  this  information  is  an  interview  and  the  official  Document 
Timeline  Calculator. 

The  decision  point  "AFROC  decision  joint  int  preC"  has  a  probability  of  90%.  Of  those  90%,  20% 
to  30%  will  have  "actions"  (Post  AFROC  "Go-do"  actions)  to  accomplish.  This  is  represented  by  "Post 
AFROC  actions  joint  int  preC."  Those  programs  with  actions  to  accomplish,  e.g.  "Post  AFROC  actions" 
must  return  to  the  AFROC.  It  has  a  time  distribution  of  0  to  15  days,  with  a  most  likely  value  of  11  days. 
If  the  initial  answer  is  "no,"  there  is  a  99%  chance  the  activity  is  "dead"  and  the  document  is  archived. 
During  validation,  the  source  indicated  he  had  never  seen  anything  go  back  through  the  AFROC  a  2nd 
time  based  on  his  25+  years  of  experience.  This  is  represented  by  first  checking  to  see  if  the  program 
had  been  rejected  at  the  AFROC  before.  If  not,  a  flag  was  set,  e.g.  "Set  tracking  point  int  preC."  Then 
the  decision  point,  "Dead  Activity  joint  int  preC"  has  a  99%  probability  that  the  program  would  be  killed 
anyway.  The  path  taken  by  the  less  than  likely  1%  of  documents  would  be  back  to  the  MAJCOM  for 
approval  through  the  comment  resolution  process  and  follow  the  normal  process  beyond  that.  The 
source  of  this  information  is  an  interview  as  well  as  review  of  official  process  documents.  It  has  been 
validated  byJCIDS  participant. 

The  next  step  is  applicable  to  50%  of  the  documents  seeking  approval.  The  other  50%  proceed 
directly  to  the  Functional  Capabilities  Board.  This  is  called  the  "Document  Review  Phase  2  Flag  level 
PreC."  This  activity  is  taking  place  because  there  were  "critical  comments"  that  were  not  resolved 
during  the  initial  round  and  the  MAJCOM  sponsor  determined  to  press  ahead  anyway.  This  step  has  a 
time  distribution  of  21  to  42  days,  with  a  most  likely  value  of  38  days.  This  has  been  validated  by  the 
Official  Document  Timeline  Calculator. 
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Figure  106:  Pre-MS  C  Requirements  swim  lane  Joint  Interest  process,  part  II 


The  next  step  is  another  round  of  the  sponsor  "Resolving  Flag  Level  Comments  PreC."  The  time 
distribution  is  15  to  30  days,  with  a  most  likely  value  of  27  days.  This  was  validated  by  the  official 
Document  Timeline  Calculator. 

The  decision  point  entitled  "MAJCOM  approval  PreC"  has  a  probability  of  99%.  The  source  of 
this  information  is  interview  and  later  validation  by  JCIDS  participant.  If  the  answer  is  no,  the  next  step 
remains  comment  resolution  and  information  is  passed  into  the  budgeting  and  programming  system  to 
deal  with  the  financial  ramifications.  Usually,  this  means  the  activity  is  put  on  "hold"  for  a  year, 
probably  the  result  of  some  "critical  comments"  that  were  not  immediately  resolved.  This  step  is  called 
"Hold  for  a  year  later  in  process  preC"  with  a  time  distribution  of  270  to  365  days,  with  a  most  likely 
value  of  300  days.  If  the  answer  is  yes,  the  activity  proceeds  to  the  next  step. 

Next  is  the  "Functional  Capabilities  Board  PreC"  for  preparation  and  validation.  This  step  has  a 
time  distribution  of  7  to  21  days,  with  a  most  likely  value  of  14  days.  This  is  considered  a  very  difficult 
"scrub"  of  the  activity.  The  model  is  programmed  to  assume  all  documents  proceed  without  problem  to 
the  next  step67.  This  step  was  validated  by  JCIDS  participant,  A5  participant,  and  the  official  Document 
Timeline  Calculator. 


Unfortunately,  this  is  not  the  case.  This  error  was  discovered  while  preparing  this  dissertation  for  publication. 
The  actual  data  is  that  70%  that  meet  the  board  go  on  to  the  next  step.  The  other  30%  have  issues  to  resolve, 
typically  taking  10  to  20  days,  with  the  most  likely  value  of  15  days  before  reporting  back  to  the  FCB.  However,  the 
likelihood  of  another  set  of  issues  arising  is  so  remote  that  it  is  assumed  to  have  a  probability  of  zero.  Given  that 
the  magnitude  of  this  error  is  on  the  order  of  a  handful  of  days  versus  the  end  result  on  the  order  of  thousands  of 
days,  it  is  judged  that  the  overall  results  in  the  dissertation  are  still  valid. 
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The  "Joint  Capabilities  Board  PreC"  requires  another  7  to  21  days  in  preparation  after  the  FCB, 


with  a  most  likely  value  of  14  days.  Following  this  is  logic,  titled  "JCB  issues  PreC,"  where  85%  that  meet 
the  JCB  board  go  on  to  the  next  step.  The  remaining  15%  have  issues  to  resolve,  titled  "Resolve  JCB 
issues  PreC,"  typically  taking  10  to  20  days,  with  a  most  likely  value  of  15  days,  before  reporting  back  to 
the  JCB.  However,  the  likelihood  of  another  set  of  issues  arising  at  the  second  meeting  of  the  JCB  is  so 
remote  that  the  model  does  not  consider  it  at  all. 

The  JROC  requires  14  to  30  days,  with  a  most  likely  value  of  25  days,  in  preparations,  e.g.  mostly 
calendar  scheduling  issues,  as  noted  in  the  step  titled,  "JROC  Preparations  PreC."  At  the  decision  point 
"JROC  PreC,"  98%  are  approved  without  issues.  The  remaining  2%  have  issues  requiring  resolution, 
typically  requiring  42  to  60  days  to  resolve,  with  a  most  likely  value  of  51  days,  as  shown  in  the  process 
step  "Resolve  JROC  issues  PreC." 

At  this  point  the  CPD  is  approved  and  the  program  resumes  the  process  flow  as  depicted  in 
Figure  101. 

Following  the  approval  of  the  CPD,  it  may  become  apparent  that  the  CPD  needs  to  be  updated. 

The  formal  process  allows  for  this  possibility.  CPD  updates  are: 

"often  a  result  of  unforeseen  program  events  (i.e.,  altering  KPPs,  budget  cuts,  significant 
schedule  delays,  technology  maturity,  leadership  intervention,  acquisition  strategy  changes, 
etc.).  Sponsors  may  update  the  CPD  before  or  after  Milestone  C.  Document  preparation, 
format,  review,  validation,  approval,  and  archiving  of  subsequent  updates  are  normally  the 
same  as  the  original  CPD."  (AFI 10-601,  pg  39) 

Joint  interest  CPDs  must  go  through  the  formal  process  to  the  JROC  for  approval.  There  is  some 
latitude  to  eliminate  some  staffing  steps  to  get  to  the  JROC,  but  that  is  by  special  request.  All  other 
CPDs  do  not  need  to  go  through  the  joint  process  for  approval. 

Regardless  of  either  having  an  updated  CPD  or  the  initial  CPD  done,  the  goal  of  the 
requirement's  system  is  to  have  the  CPD  delivered  to  the  MDA  no  later  than  60  days  prior  to  the 
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scheduled  MS  B.  This  is  another  potential  quality  check  to  test  in  the  model  and  is  reserved  for  future 


work. 


Delay  to  Align 
Funds  PreC 


Figure  107:  Pre-MS  C  PPBE  Early  funding  check 

The  PPBE  in  this  phase  does  not  change  except  that  in  addition  to  dealing  with  RDT&E  dollars, 
procurement  dollars  must  be  fully  programmed  prior  to  Milestone  C,  enough  so  that  the  program  is 
"fully  funded"  in  the  FYDP  for  both  colors  of  money.  This  will  be  discussed  later. 

Immediately  after  declaring  MS  B,  the  decision  point  "Timing  of  Funds  OK?"  is  reached.  The 
probability  of  this  step  is  55%.  This  decision  point  acknowledges  that  with  program  slips  and  delays  it  is 
possible  that  the  "fully  funded"  proposition  in  the  FYDP  may  no  longer  be  the  case,  particularly  if  a  large 
sum  of  money  was  assumed  to  be  obligated  and  expended  in  the  first  year  of  the  contract  award.  If 
"yes",  back  to  the  Acquisition  swim  lane.  If  "no",  a  process  task  entitled,  "delay  to  align  funds  PreC" 
occurs.  The  time  distribution  of  this  delay  is  30  to  75  days,  with  a  most  likely  value  of  35  days.  This 
situation  is  shorter  than  most  would  realize  due  to  the  negotiating  that  occurs  between  other  PEMs, 
etc.,  in  the  forms  of  "puts",  "takes"  and  payback  periods,  otherwise  known  as  creative  financing68. 


68  The  terms  "put,"  "take,"  and  "payback  periods"  are  used  within  the  PEM  community.  A  "put"  is  akin  to  putting 
another's  money  down  on  a  program,  while  a  "take"  is  taking  money  from  a  program.  The  "payback  period"  is  the 
period  of  time  that  moneys  that  were  "put"  or  "taken"  are  readjusted  among  the  different  programs  so  that  the 
result  is  equitable. 
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Figure  108:  Pre-MS  C  early  acquisition  swim  lane  activities 


The  first  step  in  this  phase  is  entitled  "RFP  release  and  Source  Selection  PreC".  It  has  a  time 
distribution  of  90  to  180  days,  with  a  most  likely  value  of  160  days.  The  main  assumption  is  that  there 
will  be  no  sole  source  awards  and  that  sole  source  options  are  not  part  of  the  acquisition  strategy 
completed  in  the  last  phase.  Funding  must  be  in  place  along  with  the  MS  B  declaration.  The  source  for 
this  information  is  experience,  interviews  and  documentation.  It  was  validated  via  acquisition  personnel 
from  SAF/AQ. 

A  decision  point  entitled  “Protest  award  PreC"  has  a  probability  of  20%.  The  source  of  this 
information  is  open  source  materials,  media,  and  other  documents.  If  "yes"  a  delay  is  encountered 
while  appropriate  agencies  review  the  process.  The  delay,  titled  "Delay  for  Protest  review  PreC"  can  be 
between  30  and  60  days,  with  a  most  likely  value  of  50  days.  Afterwards,  a  decision  point  entitled 
"Protest  Upheld  PreC"  is  reached.  Based  on  feedback  from  SAF/AQ  personnel  during  the  validation  of 
the  model,  the  probability  of  this  step  is  40%.  If  "yes"  the  source  selection  process  is  repeated.  If  "no", 
the  process  task  of  "Scope  and  Award  System  Design  and  Development  contracts"  is  next. 

A  task  entitled  "Scope  and  Award  System  Design  Development  contracts"  has  a  time  distribution 
of  30  to  120  days,  with  a  most  likely  value  of  100  days.  This  duration  is  dependant  upon  the  complexity 
of  the  required  task  as  well  as  if  the  study  can  be  exercised  as  a  task  or  option  on  an  existing  contract 
vehicle  or  if  a  sole  source  or  other  contracting  mechanism  is  required.  Flowever,  speed  is  favored.  The 
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time  duration  associated  with  the  length  of  the  contract  for  technology  development  has  a  distribution 


based  upon  the  ACAT  level  of  the  program.  ACAT  I  programs  have  a  contract  duration  ranging  from  365 
to  2190  days,  with  the  most  likely  value  of  1980  days.  ACAT  II  programs  have  a  contract  duration 
ranging  from  365  to  2190  days,  with  the  most  likely  value  of  1365  days.  ACAT  III  programs  have  a 
contract  duration  ranging  from  365  to  2190  days,  with  the  most  likely  value  of  480  days.  The  source  of 
this  information  is  by  inference  and  experience.  Additional  credence  can  be  found  in  official  process 
documentation.  Validation  of  these  assumptions  was  received  from  personnel  in  SAF/AQ. 

A  bookkeeping  actifact  of  the  model  is  used  to  calculate  when  the  original  end  date  of  the 
contract  should  be.  This  variable  is  used  in  some  background  calculations  used  to  determine  schedule 
growth,  etc. 

The  process  flow  continues  to  two  different  places.  First,  it  goes  into  the  Contractor  Swim  Lane 
-  reflecting  the  work  a  contractor  is  doing  -  to  be  described  later.  Second,  parallel  processes  are 
initiated  to  prepare  for  moving  the  program  into  the  next  phase  of  development. 


Figure  109:  Pre-MS  C  Acquisition  costing  and  acquisition  planning 

From  the  split  flow  in  Figure  108,  the  first  activity  is  a  queue  entitled,  "Wait  for  signal  for  Costing 
and  Acquisition  Planning  activities  preC."  This  signal  will  come  from  the  contractor  swim  lane  indicating 
a  certain  percentage  of  the  contract  is  elapsed,  which  will  be  discussed  hereafter.  It  is  a  time  delay  as 
these  activities  will  not  start  until  near  the  end  of  a  contract  and  in  preparation  of  a  Milestone  C 
declaration. 
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The  next  step  is  an  artifact  of  the  model,  requiring  parallel  processing.  This  allows  both  the  cost 


exercises  as  well  as  the  acquisition  planning  activities  to  proceed  simultaneously.  The  branch  going  to 
the  cost  area  will  be  split  again  to  allow  three  separate  costing  activities  to  proceed  in  parallel. 

The  process  task  entitled  "Acquisition  Planning  Activities  PreC"  has  a  time  distribution  of  120  to 
250  days,  with  a  most  likely  value  of  240  days  for  ACAT  I  programs.  For  ACAT  II  or  ACAT  III  programs,  the 
time  distribution  is  120  to  250  days,  with  a  most  likely  value  of  185  days.  The  source  of  this  information 
is  interviews  and  published  timelines  and  official  documentation.  It  was  validated  by  acquisition 
personnel. 

The  three  separate  costing  tasks,  "Program  Office  Cost  Estimate  PreC"  has  a  time  distribution  of 
60  to  90  days,  with  a  most  likely  value  of  65  days.  The  "Contractor  Cost  Estimate  PreC"  has  a 
distribution  of  45  to  90  days,  with  a  most  likely  value  of  50  days.  The  process  task,  "Independent  Cost 
Estimate  PreC"  has  a  distribution  of  30  to  60  days,  with  a  most  likely  value  of35  days.  The  source  of  this 
information  is  acquisition  personnel  and  validation  was  obtained  from  other  acquisition  personnel. 


Contract  Startup 

PreC 

0 


\ 

Set  Contract  Start 
variable  PreC 

_ 


Wait  for  PDR 

figure  110:  Pre-MS  C  Contract  start-up  activities 

The  initial  process  step  in  this  swim  lane  is  called  "Contract  Start-up  PreC."  It  has  a  time 
distribution  of  30  to  45  days,  with  a  most  likely  value  of  42  days.  This  is  regardless  of  the  size  and 
complexity  of  the  overall  task.  This  consists  of  the  preliminary  efforts  to  staff  the  activity  and  organize 
appropriately.  The  source  of  this  information  is  experience  and  source  documentation.  It  was  validated 
by  acquisition  personnel. 

As  an  artifact  of  the  model,  a  variable  is  set  to  record  the  "start"  of  the  contract.  Next,  a  queue 
is  met  entitled,  "Wait  for  PDR."  This  queue  waits  for  a  signal  from  the  contractor  swim  lane.  The  signal 
is  triggered  after  a  certain  period  of  contract  time  has  elapsed.  The  specifics  on  the  "Wait  for  PDR" 
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signal  will  be  discussed  later.  This  information  was  discovered  during  the  validation  phase  of  the  model 


when  working  with  acquisition  personnel. 


Figure  111:  Pre-MS  C  Early  Systems  Engineering  Preliminary  Design  Review  activity 

"Systems  Engineering"  and  "Test  and  Evaluation"  plays  a  large  role  in  this  phase  of  activity  in  the 
model.  The  model  acknowledges  these  activities  where  appropriate  as  it  assists  with  the  management 
of  the  contractor  activity.  The  first  major  activity  is  called  the  "Preliminary  Design  Review"  or  PDR.  The 
review  begins  at  a  certain  amount  of  time  elapsed  in  the  contract  depending  upon  the  ACAT  level,  which 
is  triggered  through  the  "Wait  for  PDR"  queue  discussed  earlier.  The  model  calls  the  first  PDR  check  as 
"PDR  success??"  The  probability  of  passing  this  event  successfully  is  25%.  This  information  was 
received  during  the  validation  phase  of  the  model  from  acquisition  personnel  working  closely  with  the 
acquisition  policy  shop  at  SAF/AQ.  If  "yes"  then  the  contract  schedule  is  not  affected. 

If  "no",  the  rework  time  variable  is  assigned  as  15%  of  the  elapsed  contract  time.  The  design 
work  is  re-accomplished  in  the  step  "PDR  Rework  PreC,"  with  a  time  duration  equal  to  the  rework 
variable.  Then  a  cost  and  schedule  penalty  is  added  to  the  existing  schedule.  The  artifact  of  "Assign 
PDR1  Cost  and  Schedule  Penalty"  takes  the  rework  time  and  adds  it  to  the  current  contract  length.  It 
also  adds  1%  contract  cost. 
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Another  PDR  is  met,  titled  "PDR  2"  with  the  probability  of  approval  rising  to  50%.  If  "yes",  the 


next  review  occurs  at  the  next  scheduled  interval.  If  "no",  the  "Assign  PDR2  rework"  is  given  a  value  of 
50%  of  the  previous  re-work  time.  The  task  "PDR  delay  2  PreC"  takes  this  50%  duration  to  accomplish. 
Next,  the  contract  cost  and  schedule  penalty  is  assigned  via  "Assign  PDR2  Cost  and  Schedule  Penalty". 
The  schedule  penalty  is  the  50%  rework  time  added  to  the  current  contract  length  and  another  1%  cost 
penalty  is  added  to  the  cost  variable. 

Another  PDR,  "PDR  3"  is  met  with  the  probability  rising  to  90%.  If  "yes,"  the  next  review  occurs 
at  the  next  scheduled  interval.  If  "no",  the  design  work,  e.g.  "PDR  delay  3  PreC,"  is  re-accomplished 
taking  the  previous  step's  re-work  time.  Next  the  contract  cost  and  schedule  penalty  is  assigned  via 
"Assign  PDR3  cost  and  schedule  penalty."  It  is  the  same  amount  assigned  in  the  previous  action. 

A  final  PDR  is  met  with  the  probability  rising  to  99%.  If  "yes,"  the  next  review  occurs  at  the  next 
scheduled  interval  triggered  through  the  Contractor  swim  lane.  If  "no",  the  program  is  ended,  via  the 
model  artifacts  "Assign  program  kill  at  PDR,"  "Record  16,"  "Program  Kill  at  PDR." 

The  process  then  waits  until  the  "Wait  for  CDR  trigger"  is  received  from  the  contracting  swim 

lane. 


Figure  112:  Pre-MS  C  Acquisition  swim  lane  Critical  Design  Reviews 
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When  the  signal  to  proceed  comes,  the  next  engineering  review  is  the  Critical  Design  Review  or 


CDR.  This  review  begins  at  a  time  in  the  contract  duration  depending  upon  the  ACAT  level.  This  test  is 
accomplished  in  the  Contractor  swim  lane.  The  probability  of  meeting  this  milestone,  named  "CDR 
success??"  is  70%.  If  "yes",  the  activity  proceeds  to  the  next  scheduled  activity. 

If  "no",  the  design  work  is  re-accomplished.  First  the  rework  time  is  calculated  in  the  "Assign 
CDR  Rework  time"  task.  The  rework  time  is  calculated  as  15%  of  the  elapsed  time  of  the  current 
contract.  The  rework  time  is  then  taken  in  the  step,  "CDR  Rework  PreC."  Next,  "Assign  CDR1  Cost  and 
Schedule  penalty69"  is  done  by  adding  the  rework  time  to  the  contract  length  and  end  dates,  as  well  as 
adding  1%  to  the  contract  cost. 

Another  CDR,  "CDR  2,"  is  met  with  the  probability  of  approval  rising  to  90%.  If  "yes",  the  next 
review  occurs  at  the  next  scheduled  interval. 

If  "no",  there  is  a  delay  incurred,  titled  "CDR  delay  2  PreC,"  which  takes  50%  of  the  previous  re¬ 
work  time.  Afterward,  penalties  are  assigned  by  the  artifact  "Assign  CDR  2  Cost  and  Schedule 
Penalty70."  This  is  done  by  adding  50%  of  the  rework  time  to  the  contract  length  and  end  dates,  as  well 
as  adding  1%  to  the  contract  cost. 

The  last  and  final  chance  to  complete  a  CDR  is  met  at  "CDR  3"  with  the  probability  rising  to  99%. 
If  "no",  the  program  is  ended  via  the  artifacts  of  "Assign  Program  Kill  at  CDR,"  "Record  17,"  and 


In  preparing  the  documentation  of  the  model  and  this  Appendix,  it  was  noted  that  there  was  an  error  in  one  of 
the  formulas.  Instead  of  adding  the  rework  time  to  the  contract  end  date,  the  model  was  adding  the  PDR  rework 
time  to  the  contract  end  date.  It  is  the  opinion  of  the  author  that  the  dissertation  results  remain  valid  because  the 
contract  end  date  variable  was  never  implemented  elsewhere  in  the  model.  Even  if  it  were,  the  amount  of  error 
introduced  would  be  on  the  order  of  at  most,  several  hundred  days  whereas  the  results  are  on  the  order  of 
thousands  of  days. 

70  In  preparing  the  documentation  of  the  model  and  this  Appendix,  it  was  noted  that  there  was  an  error  in  one  of 
the  formulas.  Instead  of  adding  the  rework  time  to  the  contract  end  date,  the  model  was  adding  the  PDR  rework 
time  to  the  contract  end  date.  It  is  the  opinion  of  the  author  that  the  dissertation  results  remain  valid  because  the 
contract  end  date  variable  was  never  implemented  elsewhere  in  the  model.  Even  if  it  were,  the  amount  of  error 
introduced  would  be  on  the  order  of  at  most,  several  hundred  days  whereas  the  results  are  on  the  order  of 
thousands  of  days. 
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Program  Kill  at  CDR."  If  "yes",  the  process  preparing  for  the  Design  Readiness  Review  begins,  including 


the  acquisition  panels  that  will  approve  further  development. 

The  task  "Preparation  for  Acquisition  Panels  before  DRR"  has  a  time  distribution  of  25  to  60 
days,  with  a  most  likely  value  of  50  days.  Mostly,  this  time  is  spent  to  synchronize  calendars  with  the 
fixed  acquisition  panels. 

The  task  "Pre  DRR  Acquisition  Panels"  has  a  time  distribution  of  3  to  15  days,  with  a  most  likely 
value  of  12  days.  The  DRR  tasks  were  highlighted  and  represent  an  addition  to  the  model  by  those 
personnel  in  acquisition  that  helped  with  the  validation  phase  of  the  dissertation. 


Figure  113:  Pre-MS  C  Acquisition  swim  lane  fabrication,  assembly  and  testing 

A  decision  point  entitled,  "Design  Readiness  Review"  which  includes  MDA  approval  has  a 
probability  of  90%.  If  "no"  an  artifact  of  "Check  DRR  looping  condition"  is  met.  This  point  checks  to  see 
if  the  program  has  been  through  the  loop  before. 

If  not,  the  assignment  of  "Determine  DRR  rework"  is  done.  This  is  the  result  of  a  triangular 
distribution  ranging  from  30  to  180  days,  with  a  most  likely  value  of  150  days.  Next,  the  task  of  "DRR 
rework  and  delay"  is  accomplished.  Its  duration  is  the  result  of  the  triangular  distribution.  Next,  the 
model  will  "Assign  cost  penalty  for  DRR  rework"  by  adding  the  DRR  rework  time  to  the  contract  length 
and  contract  end  date,  along  with  incurring  an  automatic  1%  cost  penalty.  A  flag  is  also  set  indicating 
the  program  has  completed  the  "loop."  Then  the  process  returns  to  the  Design  readiness  review. 
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If  the  DRR  is  successful  or  if  the  "Check  DRR  looping  condition"  has  been  used  before,  then  a 


variable  is  set  to  "notify  requirements  about  DRR  success"  and  the  program  proceeds  further. 

The  next  step  is  "Fabrication"  in  the  contractor  swim  lane.  It  has  a  triangular  distribution  of  6% 
to  11%  of  the  original  contract  length,  with  a  most  likely  value  of  10%  of  the  original  contract  length. 

This  was  validated  by  acquisition  personnel. 

"Assembly"  is  the  next  step.  It  has  the  identical  triangular  distribution  profile  as  the  previous 
step.  "Integrated  testing"  follows.  It  has  a  triangular  distribution  profile  based  upon  a  percentage  of  the 
original  contract  length  and  is  also  dependent  upon  its  ACAT  level.  For  ACAT  I  programs,  the  range  is 
15%  to  26%  of  the  original  contract  length,  with  25%  of  the  original  contract  length  being  the  most  likely 
value.  For  ACAT  II  and  III  programs,  the  range  is  7%  to  11%  of  the  original  contract  length,  with  10%  of 
the  original  contract  length  being  the  most  likely  value. 

Next,  the  "Test  Readiness  Review"  comes.  It  has  a  probability  of  70%  passing  and  proceeding  on 
to  the  next  testing  event.  If  "no,"  the  artifact  "Check  TRR  looping  condition"  looks  to  see  if  the  TRR  has 
been  met  before.  If  not,  then  the  appropriate  "Determine  TRR  delay"  is  assigned.  It  is  a  triangular 
distribution  from  30  to  180  days,  with  60  days  being  the  most  likely  value.  Next,  a  process  task  called 
"TRR  Delay  PreC"  is  met.  This  task  is  equal  to  the  delay  assigned.  The  last  step  of  the  loop,  "Determine 
cost  and  schedule  penalties  for  TRR  delays,"  adds  the  TRR  delay  to  the  contract  length  and  the  contract 
ending  date  along  with  incurring  an  automatic  1%  cost  penalty  to  the  contract  cost.  A  flag  is  set 
indicating  the  program  has  completed  the  loop.  The  program  then  returns  to  the  Test  Readiness 
Review. 

If  the  loop  has  been  completed  once  already  or  the  TRR  is  successful,  the  next  step  is 
"Developmental  system  testing  and  Live  Fire  test  and  Operational  Assessment."  It  has  a  triangular  time 
distribution  based  on  the  original  contract  length  and  the  ACAT  level.  For  ACAT  I  programs,  the  time 
distribution  ranges  from  18%  to  27%  of  the  original  contract  length,  with  25%  of  the  original  contract 
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length  being  the  most  likely  value.  For  ACAT  II  and  ACAT  III  programs,  the  time  distribution  ranges  from 


10%  to  17%  of  the  original  contract  length,  with  a  most  likely  value  of  15%  of  the  original  contract 
length.  This  was  validated  by  acquisition  personnel. 

After  developmental  testing  in  the  contractor  swim  lane,  a  decision  point  to  "make  trades?"  is 
met.  This  has  a  probability  of  50%.  Unfortunately,  historical  trends  indicate  that  many  changes  are 
desired  at  this  point.  If  trades  are  wanted,  the  looping  condition,  "Check  looping  condition"  is  checked. 
If  the  program  has  never  made  trades  before,  the  next  step  is  to  "determine  trades  delay."  It  has  a 
distribution  of  30  to  180  days,  with  a  most  likely  value  of  60  days.  Next  the  task  "trades  delay  PreC"  is 
met.  Afterward,  the  step  "Determine  cost  and  schedule  penalties  for  trades  delay"  happens  with  the 
trades  delay  being  added  to  the  length  of  the  contract  and  the  contract  ending  date,  along  with 
incurring  an  automatic  2%  cost  penalty  to  the  contract  costs.  Then  the  process  repeats  "Developmental 
system  testing  and  Live  Fire  test  and  Operational  Assessment  testing." 

If  no  trades  are  made  or  the  loop  has  already  been  completed  once,  the  step  "combined 
testing"  is  met.  This  step  has  a  triangular  distribution  based  upon  the  length  of  the  original  contract 
regardless  of  ACAT  level.  The  range  is  from  7%  to  11%  of  the  original  contract  length,  with  the  most 
likely  value  of  10%  of  the  original  contract  length. 

Finally,  upon  completion  of  all  of  these  testing  activities,  "Assign  set  close  to  end  SDD  contract 
condition."  This  simply  signals  other  activities  in  the  model  that  the  contract  is  essentially  near  its  end. 
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Figure  114:  Pre-MS  C  Acquisition  swim  lane  System  Verification  Review 

Upon  completion  of  testing,  the  program  comes  to  the  "System  Verification  Review."  It  has  a 
probability  of  85%.  If  the  program  fails,  the  artifact  labeled  "Set  SVR  rework"  is  met.  It  has  a  triangular 
distribution  of  30  to  180  days,  with  a  most  likely  value  of  160  days.  The  step  "SVR  rework  and  delay" 
requires  the  rework  time.  Next,  the  artifact  "Set  SVR  delay  cost  and  schedule  penalties"  is  met.  This 
adds  the  rework  time  to  the  contract  length  and  the  contract  end  date  while  the  cost  incurs  a  cost 
penalty  5%  the  side  of  the  current  contract  value.  Following  this  point,  the  program  returns  to  complete 
the  "Make  trades"  step. 

If  the  program  is  successful  at  SVR,  "Engineering  Development  model  delivery"  sets  a  flag 
annotating  this  event.  At  this  point,  the  "Initial  Rate  Production  Baseline"  is  set  in  an  activity  ranging 
from  15  to  35  days,  where  the  most  likely  value  is  30  days.  The  source  of  the  SVR  activities  was  official 
process  documentation  and  was  later  verified  by  acquisition  personnel. 
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Only  upon  completion  of  the  three  cost  estimates,  as  noted  by  the  queue  titled  "for  Affordability 
Assessment  PreC",  is  the  "Affordability  Assessment  PreC"  done.  The  time  duration  for  this  assessment  is 
approximately  120  to  180  days,  with  a  most  likely  value  of  160  days.  The  source  of  this  information  is 
official  documents  and  by  inference.  This  was  validated  by  acquisition  personnel. 

An  artificial  artifact  of  the  model  is  inserted  here  to  check  for  funding,  and  a  penalty  assessed  if 
it  is  not  available.  This  will  be  discussed  later. 

With  the  completed  of  the  acquisition  planning  activities  and  the  system  verification  review 
completed,  both  shown  previously,  the  process  task,  "Draft  RFP  Preparation  PreC"  may  begin.  It  takes 
10  to  20  days,  with  a  most  likely  value  of  17  days.  Typically  there  is  some  effort  to  waive  the  firm 
prerequisites  and  preliminary  results  will  be  used,  especially  if  trying  to  meet  a  "target"  MS  C  date  goal, 
but  the  model  does  not  attempt  to  account  for  this  variation.  The  source  of  this  information  is 
experience  and  source  documents,  and  was  subsequently  validated  by  acquisition  personnel.  Outputs 
from  this  step  go  to  two  different  tasks  -  one  related  to  the  RFP  coordination  process,  and  another  to 
the  development  of  the  Source  Selection  plans. 

A  process  task  called  "RFP  coordination  process  PreC"  has  a  time  distribution  of  25  to  50  days, 
with  a  most  likely  value  of  45  days.  Some  of  this  coordination  is  done  within  the  branch  of  service  doing 
the  acquisition  and  some  of  it  is  done  with  industry.  The  source  of  this  information  is  interviews, 
experience  and  source  documents.  It  was  later  validated  by  acquisition  personnel. 
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There  is  a  queue,  "wait  for  baseline  set  preC,"  that  must  be  released  by  the  proper  trigger 


before  proceeding  to  the  process  task,  "source  selection  plans  preC"  which  has  a  time  distribution  of  30 
to  65  days,  with  a  most  likely  value  of  60  days.  This  time  duration  is  influenced  by  the  current  state  of 
the  contractor's  work  which  impacts  the  final  requirements  that  are  going  to  be  part  of  the  future 
contracting  effort.  The  source  of  this  information  is  experience  and  published  timelines.  Validation  was 
provided  by  acquisition  personnel. 

An  artifact  of  the  model  brings  the  RFP  coordination  process  and  completion  of  the  cost 
estimates  together. 

Upon  return  from  the  funding  check,  and  also  as  the  CPD  is  being  finalized  in  the  requirements 
swim  lane,  the  approved  KPPs  will  be  released  to  the  Acquisition  swim  lane.  At  this  point  the  Acquisition 
program  baseline  will  be  set.  This  marks  the  "official"  baseline  for  the  remaining  program  and  will  be 
the  benchmark  against  which  all  further  development  from  this  point  will  be  measured.  It  is  not  unusual 
for  these  attributes  to  be  set  based  on  draft  or  preliminary  documents.  The  task  has  a  time  distribution 
of  10  to  30  days,  with  a  most  likely  value  of  25  days.  A  model  artifact  "notify  PreC  Baseline"  is  set.  The 
source  of  this  information  is  official  documents  and  inference.  It  was  later  validated  by  acquisition 
personnel. 

An  artifact  of  the  model  brings  two  parallel  paths  together  with  the  activity  called  "Complete 
predecessor  activities  preC."  These  paths  are  from  the  funding  check  and  the  source  selection  plans 
activities. 

The  process  task  for  the  preparation  for  the  Acquisition  Panels  has  a  time  distribution  of  40  to 
60  days,  with  a  most  likely  value  of  56  days  for  ACAT  I  programs.  For  the  ACAT  II  and  ACAT  III  programs, 
the  preparation  requires  15  to  30  days,  with  a  most  likely  value  of  25  days.  The  majority  of  this  time  is 
to  get  in  synchronization  with  the  set  calendar  of  these  panels.  Most  of  the  "work"  has  already  been 
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done  prior  to  this  time  in  previous  tasks.  The  source  of  this  information  is  an  interview  and  source 
documents.  It  was  later  validated  by  acquisition  personnel. 

Once  the  RFP  Coordination  process  is  complete,  along  with  the  acquisition  panel  preparations, 
the  process  task  entitled  "Acquisition  Panels  PreB"  is  met.  It  has  a  time  distribution  of  15  to  35  days, 
with  a  most  likely  value  of  30  days.  The  time  distribution  allows  for  delays  and  resolution  of  last  minute 
issues  in  these  events. 


Figure  116:  Pre-MS  C  PPBE  Funding  check 


Despite  the  discrete  nature  of  the  model  the  PPBE  is  constantly  seeking  updates  to  the  cost  and 
schedule  updates  for  the  system.  The  response  of  the  model  to  this  input  is  a  decision  point  entitled 
"Funds  set  aside  for  next  phase  in  FYDP  at  80%  of  ICE  amount  PreC".  This  decision  point  has  a 
probability  of  90%.  This  means  that  the  Air  Force  is  making  an  investment  decision  into  the 
development  of  this  concept.  The  irony  is  that  the  decision  to  fund  at  this  level  is  made  within  the 
corporate  structure  of  the  Air  Force,  e.g.  within  the  Budgeting  and  Programming  system,  and  the 
acquisition  System  with  its  accompanying  Milestone  decision  is  merely  a  ratification  of  the  previously 
taken  action  by  the  Air  Force. 

If  the  decision  is  "no",  a  time  delay  is  incurred.  The  time  delay  task  has  a  time  distribution  of  30 
to  180  days,  with  a  most  likely  value  of  120  days  for  ACAT  I  programs.  For  ACAT  II  and  ACAT  III 
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programs,  the  time  distribution  is  90  to  270  days,  with  a  most  likely  value  of  225  days.  The  reason  for 


these  distributions  is  that  significant  resources  have  been  expended  by  the  Air  Force  to  date  and  there  is 
tremendous  institutional  pressure  to  continue  the  development  of  the  concept.  This  does  have  a  direct 
impact  on  reaching  Milestone  C  -  the  program  must  be  fully  funded,  e.g.  at  80%  of  the  ICE  amount,  in 
order  to  proceed  further.  It  is  even  more  important  at  this  point  because  not  only  must  the  moneys  be 
there  for  RDT&E  dollars,  but  also  for  Production  dollars,  which  will  be  used  predominately  post¬ 
milestone  C.  In  reality,  this  means  that  if  the  money  still  isn't  there,  having  the  plan  in  place  prevents 
further  delays,  but  it  still  doesn't  guarantee  the  program  will  be  fully  funded.  Furthermore,  it  is  also 
likely  the  program  is  funded  to  the  Program  Office  Cost  estimate,  which  is  historically  lower  than  ICE 
estimates. 


Figure  117:  Pre-MS  C  Acquisition  swim  lane  Milestone  B  decision 

Upon  formal  receipt  of  the  approved  CPD  from  the  requirements  swim  lane,  the  milestone 
decision  can  be  made.  A  decision  point  entitled  "MDA  Milestone  Approval  PreC"  has  a  probability  of 
99%.  This  probability  relies  upon  the  confluence  of  all  previous  tasks  preparing  for  the  next  phase  of 
acquisition  development  and  the  approved  CPD  from  the  requirements  swim  lane.  The  source  of  this 
information  is  official  documents  and  subsequent  validation  from  acquisition  personnel. 
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If  "no",  a  check  is  made  to  see  if  the  program  has  failed  previously.  If  so,  the  program  is  killed. 


If  not,  a  counter  is  attached  to  the  program  to  indicate  the  milestone  failure.  Officially,  the  process 
returns  to  the  "Preparation  for  Acquisition  Panels"  step  to  repeat  the  entire  process  from  there. 
However,  the  MDA  can  reject  the  program  for  various  reasons  and  the  personnel  working  the  program 
would  go  back  to  the  portions  that  needed  to  be  redone  and  fix  them.  Therefore,  an  artificial  step 
entitled  "Delay  to  repeat  required  steps  PreC,"  was  created.  It  has  a  time  distribution  of  60  to  180  days, 
with  a  most  likely  value  of  120  days.  After  completion  of  this  step,  the  program  then  returns  to  the 
MDA  decision  point.  If  the  program  is  rejected  twice,  the  process  ends,  as  evidenced  with  the  model 
artifacts  of  "End  Simulation  PreC  4,"  "Record  14,"  and  "Kill  at  MS  C  decision."  In  essence,  this  means  the 
sponsoring  MAJCOM  will  withdraw  its  support  and/or  funding  and/or  restructure  the  program  by  going 
back  to  the  beginning  of  the  overall  process.  If  the  MDA  approves  the  program,  Milestone  "C"  is 
declared.  The  "program"  contains  all  of  the  information,  approval,  and  consent  needed  to  proceed  into 
the  next  phase  of  activity.  Since  Milestone  C  was  the  declared  goal  of  the  model's  scope,  the  model  will 
also  end  at  the  "Milestone  C  decision"  with  model  artifacts  of  "End  simulation,"  "Record  15,"  and  "End 
at  MS  C." 
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Figure  118:  Pre-MS  C  Acquisition  swim  lane  financial  uncertainty  engine 

Contract  management  is  not  explicitly  modeled.  However,  several  other  activities  are  modeled 
that  can  be  used  a  surrogates  for  this  activity.  The  first  step  in  this  surrogate  activity  mentioned  is  the 
generation  of  a  "Program  Review  Condition  PreC."  Depending  upon  the  ACAT  level,  this  activity  would 
generate  a  potential  program  review.  If  the  program  in  question  was  ACAT  I,  the  condition  would  be 
invoked  using  a  triangular  distribution  between  90  and  120  days,  with  a  most  likely  value  of  105  days. 

For  ACAT  II  programs,  this  triangular  distribution  is  between  160  and  200  days,  with  a  most  likely  value 
of  180  days.  For  ACAT  III  programs,  the  triangular  distribution  is  between  160  and  200  days,  with  the 
most  likely  value  of  200  days.  Originally,  these  distributions  were  longer,  on  the  order  of  about  every  six 
months  to  mimic  the  behavior  of  the  Spring  and  Fall  program  reviews.  Many  of  those  who  helped 
validate  the  model  took  exception  to  this  approach  and  indicated  that  whether  under  a  formal  review  or 
not,  the  frequency  of  these  serious  funding  questions  was  tied  to  the  ACAT  level.  The  Higher  the  ACAT 
level,  the  more  frequent  reviews  are  or  with  a  lower  ACAT  level,  the  less  frequent  the  reviews  are. 
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Therefore,  the  ACAT  III  programs  approach  a  nearly  six  month  review  cycle  while  the  ACAT  I  programs 


are  more  frequent. 

A  check  is  made  to  see  if  the  contract  has  started  yet.  If  not,  the  condition  is  "thrown  away"  via 
the  model  artifact  "Dispose  of  program  review  prior  to  need  PreC."  Otherwise,  the  program  condition 
meets  a  decision  point  called  "Program  review  OK  PreC."  It  has  a  probability  of  95%.  A  future  work 
modification  would  make  this  probability  variable,  as  the  number  of  "unanticipated  events"  increases, 
as  discussed  later,  the  probability  should  slowly  decrease. 

If  the  result  of  the  program  review  is  "yes",  another  decision  point  is  reached  called  "Funds 
Redirected  PreC."  This  decision  point  has  a  probability  of  20%.  The  source  of  this  information  is 
interviews  and  inference,  and  later  validation.  This  speaks  to  the  fact  that  even  though  a  program  may 
be  doing  well,  outside  influences  may  have  already  decided  to  make  financial  changes  anyway. 

If  the  outcome  of  the  program  review  is  negative  or  the  outcome  of  the  "funds  redirected"  point 
is  "yes",  then  the  process  is  directed  to  a  task  called  "Prepare  Courses  of  Action,"  which  will  be 
discussed  later.  A  negative  outcome  from  the  "funds  redirected"  step  will  end  the  condition  with  the 
model  artifact  "End  of  Program  Review  Loop  PreC." 
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Figure  119:  Pre-MS  C  Contractor  swim  lane  uncertainty  generator  and  contract  engine 

The  contractor  portion  of  the  model  is  significantly  less  complex  than  the  other  portions  of  the 
model.  However,  this  part  of  the  model  captures  an  important  interaction  that  can  serve  as  one 
surrogate  for  uncertainty.  This  surrogate  is  easily  recognizable  and  often  mentioned  in  the  literature  as 
"stuff  happens".  The  abstractions  in  this  swim  lane  will  still  keep  this  surrogate  viable,  but  won't  cause 
it  to  be  too  complex  for  understanding.  The  first  task  is  to  generate  an  uncertainty  event.  This  occurs 
on  a  frequency  modeled  by  a  triangular  distribution  with  a  range  between  30  and  90  days,  with  a  most 
likely  value  of  60  days.  During  the  validation  of  the  model,  acquisition  professionals  pointed  out  that  the 
kinds  of  things  that  required  their  attention  outside  of  their  normal  job  descriptions  relating  to  the 
program  in  development  happened  about  every  two  months. 
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The  check  point  "Event  Happens  preC"  waits  for  the  contract  to  start.  If  the  contract  has  not 


started,  the  uncertainty  event  is  thrown  away,  as  evidenced  by  the  model  artifact  "Dispose  of  event 
happens  prior  to  need  PreC."  If  it  has  started,  the  event  proceeds  to  the  next  step,  e.g.  an  "event"  has 
happened.  These  are  the  larger  issues  that  arise  during  the  day-to-day  performance  of  the  contract. 
This  task  serves  largely  as  the  surrogate  for  uncertainty.  The  source  of  this  information  is  experience 
and  the  assumptions  required  for  this  model  to  work. 

A  decision  point  called  "Scope  Growth  Technical  Problems  PreC"  has  a  probability  of  20%.  The 
smaller  probability  is  a  trade-off  between  the  short  time  duration  of  the  previous  step  and  the 
probability  that  troubles  really  do  occur  over  the  course  of  a  contract.  If  "yes",  the  flow  is  split,  so  that 
one  "event"  moves  to  a  process  step  in  the  Acquisition  Swim  Lane,  "Prepare  Courses  of  Action,"  which 
will  be  discussed  later.  Additionally,  the  process  flows  in  the  direction  of  another  decision  point,  called 
"Contract  Complete?"  The  source  of  this  information  is  experience  and  is  required  to  make  the  model 
work. 

First,  a  check  is  made  to  see  if  the  program  is  ready  for  the  "Preliminary  Design  Review"  or  not. 
It  checks  to  see  if  25%  of  the  original  contract  length  has  transpired.  If  so,  the  model  next  checks  to  see 
that  the  "Trigger  PDR  once"  has  only  been  done  once.  If  it  is  the  first  time,  the  artifact  "Change  PDR 
variable  is  set  accordingly  to  set  other  processes  in  motion  and  also  to  prevent  other  events  from  going 
down  this  particular  path.  Regardless  of  the  outcome,  as  long  as  PDR  has  started,  the  next  check  to 
make  is  about  the  "Critical  Design  Review."  If  45%  of  the  contract  length  has  transpired,  the  CDR  will  be 
triggered.  First,  the  model  checks  to  see  that  the  CDR  is  only  triggered  once.  If  it  is  the  first  time, 
"Change  CDR  variable"  is  changed  to  reflect  the  start  of  the  CDR. 

The  next  decision  point  is  to  query  if  the  contract  length  is  within  6  months  of  contract 
completion.  If  "yes",  the  next  step  is  to  query  if  it  is  the  first  time.  If  "yes",  then  this  triggers  the 
Acquisition  Planning  Activity  step  and  the  three  costing  activities.  It  also  sets  a  flag  indicating  it  has 
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tripped  the  contractor  loop  so  subsequent  events  won't  go  down  this  path  again  and  then  proceeds  to 


the  next  step.  If  the  event  is  met  with  "no"  to  either  question,  the  flow  proceeds  to  the  next  step  as 
well. 

The  decision  point  "Contract  Complete  preC"  is  a  simple  logic  test  to  see  if  the  total  time 
elapsed  is  greater  than  total  of  the  contract  starting  time  and  the  contract  length.  If  "no",  the  event  is 
removed  from  the  model  using  the  artifact,  "End  of  Event  Happens  Loop  PreC."  If  "yes",  a  query  is  made 
to  see  if  this  is  the  first  time  the  event  has  arrived  at  this  point.  If  the  query  is  affirmative,  the  final 
variable  for  the  future  work  extension  on  the  final  contract  cost,  which  will  be  explained  later,  is  set. 
Then  the  event  is  disposed  at  the  "Completion  of  contract  PreC."  If  the  query  is  false,  is  it  immediately 
sent  also  to  the  artifact  "Completion  of  contract  PreC"  for  disposal. 

This  particular  approach  was  used  to  accommodate  multiple  "events"  working  their  way 
through  the  system  at  any  given  time  and  be  able  to  trigger  events  appropriately. 


Figure  120:  Pre-MS  C  Acquisition  swim  lane  program  management  and  oversight  loop 


This  particular  set  of  activities  drew  the  most  scrutiny  during  the  validation  portion  of  the  model 
development,  especially  from  the  acquisition  personnel.  Many  changes  were  made  to  the  model  based 
upon  their  feedback. 

Whether  an  "event"  or  a  "program  review  condition"  appears  at  the  step,  "Prepare  Courses  of 
Action  PreC,"  it  is  treated  the  same.  The  task,  "Prepare  Courses  of  Action  PreC"  has  a  time  distribution 
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of  5  to  10  days,  with  a  most  likely  value  of  8  days.  This  gets  into  the  daily  activities  of  the  office 
managing  the  program  and  dealing  with  issues.  The  source  of  this  information  is  personal  experience, 
interviews  and  inference.  Acquisition  personnel  validated  the  information  at  this  step. 

At  this  point,  80%  of  the  process  flow  will  proceed  down  the  "Scope  Growth/Technical 
problems"  path.  The  other  20%  will  follow  the  "Funding  Problem"  path.  The  source  of  this  information 
is  from  interviews,  inference  and  personal  experience.  Regardless  of  the  reason,  since  scope  growth 
and  technical  issues  can  also  be  boiled  down  to  financial  impacts,  the  rest  of  the  diagram  deals  with 
financial  issues. 

A  decision  point,  "Funding  problem  Contract  Change  Required  PreC"  has  a  probability  of  40%.  A 
future  work  extension  to  the  model  to  make  it  more  realistic  would  be  to  allow  this  probability  to  slowly 
increase  depending  upon  the  total  number  of  "events"  that  have  happened.  If  "false",  the  event  or 
program  review  condition  is  disposed  at  the  model  artifact  "End  of  contract  change  path."  If  "true," 
several  quality  values  are  set.  These  quality  values  will  determine  the  percentage  of  cost  and  schedule 
growth  added  in  a  later  step. 

The  decision  point  named  "Seek  Funds  PreC"  has  a  probability  of  30%.  This  probability  is 
influenced  by  whether  or  not  the  program  can  deal  with  the  event  or  problem  on  its  own.  The  reason 
for  the  "problem"  may  be  outside  of  the  acquisition  swim  lane.  If  "yes",  a  task  entitled  "PEM  or  other 
staff  find  money  PreC"  begins.  It  has  a  time  duration  of  14  days  to  180  days  for  ACAT  I  programs,  with  a 
most  likely  value  of  83  days.  For  ACAT  II  and  ACAT  III  programs,  there  is  a  longer  timeline  associated 
with  finding  funds,  having  the  same  distribution,  but  the  most  likely  value  is  160  days.  This  time 
duration  is  influenced  by  the  fact  that  there  are  many,  many  sources  of  money.  These  sources  can  be 
other  programs,  results  of  different  "periodic  reviews"  and  other  items.  Sometimes,  the  movement  of 
money  must  rely  upon  approval  from  higher  levels,  up  to  and  including  Congress.  Additionally,  the 
timing  of  when  the  request  goes  in,  e.g.  the  month  of  the  year  compared  to  the  POM  cycle  and  the 
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overall  amount  required,  affects  the  ability  of  the  PEM  to  find  the  money  required,  e.g.  the  more  money 


requested,  the  longer  amount  of  time  is  necessary  to  obtain  it.  This  step  was  validated  by  PPBE  and 
acquisition  personnel. 

As  an  aside,  in  the  case  of  budget  execution  problems,  another  task  is  invoked  but  it  is  not 
represented  in  the  model.  It  is  called  "Prepare  Program  budget  decision  information."  This  task  feeds 
directly  into  the  budgeting  and  programming  process.  It  is  used  in  subsequent  iterations  of  the  PPBE 
process.  The  source  of  this  information  is  official  documentation  and  inference. 

A  decision  point  entitled,  "Obtain  funds  in  a  timely  manner  PreC"  has  a  probability  of  65%.  This 
probability  is  influenced  by  the  fact  that  there  are  many,  many  sources  of  money.  These  sources  can  be 
other  programs,  results  of  different  "periodic  reviews"  and  other  items.  Sometimes  having  the  money 
arrive  "late"  is  just  as  bad  as  or  worse  than  not  getting  the  money  at  all  due  to  the  various  funding 
constraints  associated  with  the  funds.  The  source  of  this  information  is  inference  and  experience.  If 
true,  e.g.  moneys  are  obtained  in  a  timely  manner,  the  impact  will  be  a  4.5%  growth  in  the  cost  and 
schedule  of  the  program.  If  false,  e.g.  moneys  are  not  obtained  in  a  timely  manner,  the  impact  will  be  a 
5.5%  growth  in  the  cost  and  schedule  of  the  program.  These  penalties  will  be  assessed  in  a  later  step. 

A  process  task,  "Change  contract  or  re-scope  contract  PreC"  has  a  time  distribution  of  15  to  60 
days,  with  a  most  likely  value  of  20  days,  where  the  variation  is  dependent  upon  the  scale  of  contract 
change  and  the  complexity  of  the  change.  This  is  associated  with  the  actual  time  required  to  process  a 
contract  change.  The  source  of  this  information  is  experience  and  inference. 

Appendix  A  provides  some  insights  into  the  various  causes  of  cost  and  schedule  growth, 
enumerated  through  an  extensive  literature  search.  In  some  sense,  the  randomness  of  the  outcomes  is 
dependent  upon  where  in  the  system  the  activity  occurs.  For  purposes  of  simplicity,  an  assumption  that 
with  every  contract  change,  a  5%  schedule  and  cost  penalty  should  be  assessed,  is  made.  This 
approximation  was  validated  as  reasonable  by  acquisition  personnel. 
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The  step  "Set  cost  and  schedule  penalties  PreC"  is  where  an  adjustment  to  the  program  is  made; 
reflected  in  terms  of  cost  and  schedule71.  The  degree  to  which  both  cost  and  schedule  will  be  changed  is 
dependent  upon  the  quality  variables  set.  Cost  and  schedule  will  either  experience  a  4.5%,  a  5%,  or  a 
5.5%  growth  to  their  current  baseline  status.  As  multiple  issues  can  be  working  their  way  through  the 
system  at  any  given  time,  there  is  a  potential  for  large  cost  and  schedule  growth  to  occur. 

Following  this  activity,  the  "event"  or  "program  review  condition"  is  permanently  removed  from 
the  model  through  the  model  artifact  of  "End  of  Program  Management  and  Oversight  loop  PreC." 

Summary 

This  model  represents  the  first  of  its  kind  to  methodically  document  at  a  high  level  of 
abstraction  the  big  "A"  of  Acquisition  -  comprised  of  the  three  major  systems  within  the  AF,  e.g. 
Requirements,  PPBE,  and  Acquisition,  -  in  a  manner  that  is  simple  to  follow  and  gains  transparency  into 
the  overall  functioning  of  this  system.  It  does  so  by  combining  the  "official"  process  flow  with  observed 
realities  and  validated  observations  of  the  probabilities  and  time  required  with  the  different  steps. 

It  is  hoped  that  this  model  marks  the  beginning  of  better  understanding  into  the  overall 
functioning  of  the  big  "A"  of  Acquisition  of  systems  in  the  US  Air  Force  and  other  large  complex 
development  systems. 


71  Since  it  has  already  been  noted  that  schedule  is  a  reasonable  surrogate  for  cost  or  rather,  is  closely  tied  to  cost, 
the  model  only  closely  tracks  schedule.  The  "hooks"  are  there  for  future  work  to  add  cost  as  an  explicit  part  of  the 
model. 
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Appendix  E  -  Model  Documentation 

SI  MAN  Code 

SIMAN  view  of  model 


Model  statements  for  module:  BasicProcess. Create  1  (Start  model) 


683$ 

CREATE, 

684$ 

ASSIGN: 

l,DaysToBaseTime(0),ldea:DaysToBaseTime(EXPO(l)),l:NEXT(684$); 
Start  model. NumberOut=Start  model. NumberOut  +  1:NEXT(657$); 


;  Model  statements  for  module:  BasicProcess. Assign  147  (Assign  Beginning  simulation  time) 
/ 

657$  ASSIGN:  SimTime=TNOW:NEXT(0$); 


;  Model  statements  for  module:  BasicProcess. Process  1  (Random  Entry  Point) 

/ 

0$  ASSIGN:  Random  Entry  Point. Numberln=Random  Entry  Point. Numberln  +  1: 

Random  Entry  Point. WIP=Random  Entry  Point. WIP+1; 

688$  DELAY:  Uniform(l,365)„Other; 

735$  ASSIGN:  Random  Entry  Point. NumberOut=Random  Entry  Point. NumberOut  +  1: 

Random  Entry  Point. WIP=Random  Entry  Point. WIP-1:NEXT(35$); 


;  Model  statements  for  module:  BasicProcess. Process  17  (Set  ACAT  level) 

/ 

35$  ASSIGN:  Set  ACAT  level. Numberln=Set  ACAT  level. Numberln  +  1: 

Set  ACAT  level. WIP=Set  ACAT  level.WIP+l:NEXT(36$); 

36$  BRANCH,  1: 
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With,(62)/100,37$,Yes: 

With,(14)/100,38$,Yes: 

With,(5)/100,39$,Yes: 

With,(9)/100,41$,Yes: 

With,(8)/100,42$,Yes: 

Else, 40$, Yes; 


40$ 

ASSIGN: 

ACAT  Level=l:NEXT(786$); 

37$ 

ASSIGN: 

ACAT  Level=3:NEXT(786$); 

38$ 

ASSIGN: 

ACAT  Level=2:NEXT(786$); 

39$ 

ASSIGN: 

ACAT  Level=l:NEXT(786$); 

41$ 

ASSIGN: 

ACAT  Level=l:NEXT(786$); 

42$ 

ASSIGN: 

ACAT  Level=l:NEXT(786$); 

786$ 

ASSIGN:  Set  ACAT  level. NumberOut=Set  ACAT  level. NumberOut  +  1 

Set  ACAT  level. WIP=Set  ACAT  level.WIP-l:NEXT(l$); 

;  Model  statements  for  module:  BasicProcess. Decide  1  (For  existing  Program?) 

/ 

1$  BRANCH,  1: 

With, (75)/100, 791$, Yes: 

Else, 792$, Yes; 

791$  ASSIGN:  For  existing  Program?. NumberOut  True=For  existing  Program?. NumberOut  True 

+  1:NEXT(2$); 

792$  ASSIGN:  For  existing  Program?. NumberOut  False=For  existing  Program?. NumberOut  False 

+  1:NEXT(16$); 


;  Model  statements  for  module:  BasicProcess. Process  2  (Route  to  Proper  Organization) 

/ 

2$  ASSIGN:  Route  to  Proper  Organization. Numberln=Route  to  Proper  Organization. Numberln 

+  1: 
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Route  to  Proper  Organization. WIP=Route  to  Proper  Organization. WIP+1; 

794$  DELAY:  Triangular(3,3,7)„Tran; 

841$  ASSIGN:  Route  to  Proper  Organization. NumberOut=Route  to  Proper 

Organization. NumberOut  +  1: 

Route  to  Proper  Organization. WIP=Route  to  Proper  Organization. WIP-1:NEXT(3$); 


;  Model  statements  for  module:  BasicProcess. Decide  2  (In  Scope  of  Existing  document?) 

/ 

3$  BRANCH,  1: 

With, (85)/100, 844$, Yes: 

Else, 845$, Yes; 

844$  ASSIGN:  In  Scope  of  Existing  document?. NumberOut  True=ln  Scope  of  Existing 

document?. NumberOut  True  +  1 
:NEXT(4$); 

845$  ASSIGN:  In  Scope  of  Existing  document?. NumberOut  False=ln  Scope  of  Existing 

document?. NumberOut  False  +  1 
:NEXT(13$); 


;  Model  statements  for  module:  BasicProcess. Process  3  (Prepare  for  Acquisition) 

/ 

4$  ASSIGN:  Prepare  for  Acquisition. Numberln=Prepare  for  Acquisition. Numberln  +  1: 

Prepare  for  Acquisition. WIP=Prepare  for  Acquisition. WIP+1; 

847$  DELAY:  Triangular(5,7,1460)„VA; 

894$  ASSIGN:  Prepare  for  Acquisition. NumberOut=Prepare  for  Acquisition. NumberOut  +  1: 

Prepare  for  Acquisition. WIP=Prepare  for  Acquisition. WIP-1:NEXT(5$); 


;  Model  statements  for  module:  BasicProcess. Decide  3  (Rejection  outright) 
/ 

5$  BRANCH,  1: 

With, (55)/100, 897$, Yes: 

Else, 898$, Yes; 
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897$  ASSIGN:  Rejection  outright. NumberOut  True=Rejection  outright. NumberOut  True  + 

1:NEXT(354$); 


898$  ASSIGN:  Rejection  outright. NumberOut  False=Rejection  outright. NumberOut  False  + 

1:NEXT(6$); 


;  Model  statements  for  module:  BasicProcess. Assign  56  (End  simulation  1) 
/ 

354$  ASSIGN:  Early  Archive=TNOW: 

TFIN=TNOW:NEXT(656$); 


;  Model  statements  for  module:  BasicProcess. Record  1  (Record  1) 
/ 

656$  TALLY:  Record  l,INT(SimTime),l:NEXT(15$); 


;  Model  statements  for  module:  BasicProcess. Dispose  3  (Early  Archive  End) 

/ 

15$  ASSIGN:  Early  Archive  End.NumberOut=Early  Archive  End. NumberOut  +  1; 

899$  DISPOSE:  No; 


;  Model  statements  for  module:  BasicProcess. Decide  4  (OR  junction) 

/ 

6$  BRANCH,  1: 

With, (75)/100, 900$, Yes: 

Else, 901$, Yes; 

900$  ASSIGN:  OR  junction. NumberOut  True=OR  junction. NumberOut  True  +  1:NEXT(7$); 

901$  ASSIGN:  OR  junction. NumberOut  False=OR  junction. NumberOut  False  +  1:NEXT(8$); 
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;  Model  statements  for  module:  BasicProcess. Process  4  (to  Acquisition  Modernization  or  Sustainment 
Activity) 

/ 

7$  ASSIGN:  to  Acquisition  Modernization  or  Sustainment  Activity. Numberln= 

to  Acquisition  Modernization  or  Sustainment  Activity. Numberln  +  1: 
to  Acquisition  Modernization  or  Sustainment  Activity. WIP= 
to  Acquisition  Modernization  or  Sustainment  Activity. WIP+1; 

903$  DELAY:  Triangular(180,903,1460)„VA; 

950$  ASSIGN:  to  Acquisition  Modernization  or  Sustainment  Activity. NumberOut= 

to  Acquisition  Modernization  or  Sustainment  Activity. NumberOut  +  1: 
to  Acquisition  Modernization  or  Sustainment  Activity. WIP= 
to  Acquisition  Modernization  or  Sustainment  Activity. WIP-1:NEXT(10$); 


;  Model  statements  for  module:  BasicProcess. Decide  6  (MDAP  Threshold  crossed?) 
/ 

10$  BRANCH,  1: 

With, (10)/100, 953$, Yes: 

Else, 954$, Yes; 

953$  ASSIGN:  MDAP  Threshold  crossed?. NumberOut  True=MDAP  Threshold 

crossed?. NumberOut  True  +  1:NEXT(11$); 

954$  ASSIGN:  MDAP  Threshold  crossed?. NumberOut  False=MDAP  Threshold 

crossed?. NumberOut  False  +  1:NEXT(355$); 


;  Model  statements  for  module:  BasicProcess. Decide  7  (Which  Milestone  after  MDAP  threshold?) 
/ 

11$  BRANCH,  1: 

With, (24)/100, 678$, Yes: 

With, (75)/100, 679$, Yes: 

Else, 677$, Yes; 


Model  statements  for  module:  BasicProcess. Record  36  (Record  36) 


677$  TALLY: 


Record  36,INT(SimTime),l:NEXT(636$); 


;  Model  statements  for  module:  BasicProcess. Assign  132  (Reinsert  into  Acquisition  Process  A) 
/ 

636$  ASSIGN:  Back  into  process  at  A  time=TNOW: 

Back  into  process  at  PreA=l:NEXT(120$); 


;  Model  statements  for  module:  BasicProcess. Decide  48  (Check  for  ACAT  level  for  potential  AoA) 
/ 

120$  BRANCH,  1: 

If, ACAT  Level==l,957$,Yes: 

Else, 958$, Yes; 

957$  ASSIGN:  Check  for  ACAT  level  for  potential  AoA. NumberOut  True= 

Check  for  ACAT  level  for  potential  AoA. NumberOut  True  +  1:NEXT(149$); 

958$  ASSIGN:  Check  for  ACAT  level  for  potential  AoA. NumberOut  False= 

Check  for  ACAT  level  for  potential  AoA. NumberOut  False  +  1:NEXT(123$); 


;  Model  statements  for  module:  BasicProcess. Process  71  (Develop  AoA  Plan  ACAT  I) 

/ 

149$  ASSIGN:  Develop  AoA  Plan  ACAT  I.Numberln=Develop  AoA  Plan  ACAT  I.Numberln  +  1: 

Develop  AoA  Plan  ACAT  I.WIP=Develop  AoA  Plan  ACAT  I.WIP+1; 

960$  DELAY:  Triangular(60,75,90)„VA; 

1007$  ASSIGN:  Develop  AoA  Plan  ACAT  I.NumberOut=Develop  AoA  Plan  ACAT  I. NumberOut  +  1: 

Develop  AoA  Plan  ACAT  I.WIP=Develop  AoA  Plan  ACAT  I.WIP-1:NEXT(121$); 


;  Model  statements  for  module:  BasicProcess. Decide  49  (ACAT  1  funding) 
/ 

121$  BRANCH,  1: 
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With,  (70)/100, 1010$; Yes: 

Else, 1011$, Yes; 

1010$  ASSIGN:  ACAT  1  funding. NumberOut  True=ACAT  1  funding. NumberOut  True  + 

1:NEXT(141$); 

1011$  ASSIGN:  ACAT  1  funding. NumberOut  False=ACAT  1  funding. NumberOut  False  + 

1:NEXT(122$); 


;  Model  statements  for  module:  BasicProcess. Decide  57  (ACAT  level  check  for  Acquisition  swimlane 
preA) 

/ 

141$  BRANCH,  1: 

If, ACAT  Level==l,  1012$, Yes: 

Else, 1013$, Yes; 

1012$  ASSIGN:  ACAT  level  check  for  Acquisition  swimlane  preA. NumberOut  True= 

ACAT  level  check  for  Acquisition  swimlane  preA. NumberOut  True  +  1:NEXT(142$); 

1013$  ASSIGN:  ACAT  level  check  for  Acquisition  swimlane  preA. NumberOut  False= 

ACAT  level  check  for  Acquisition  swimlane  preA. NumberOut  False  +  1:NEXT(143$); 


;  Model  statements  for  module:  BasicProcess. Process  68  (ACAT  I  prepare  for  Acquisition  panels) 

/ 

142$  ASSIGN:  ACAT  I  prepare  for  Acquisition  panels. Numberln=ACAT  I  prepare  for  Acquisition 

panels. Numberln  +  1: 

ACAT  I  prepare  for  Acquisition  panels. WIP=ACAT  I  prepare  for  Acquisition  panels. WIP+1; 
1015$  DELAY:  Triangular(40,55,60)„VA; 

1062$  ASSIGN:  ACAT  I  prepare  for  Acquisition  panels. NumberOut=ACAT  I  prepare  for 

Acquisition  panels. NumberOut  +  1: 

ACAT  I  prepare  for  Acquisition  panels. WIP=ACAT  I  prepare  for  Acquisition  panels. WIP- 

1:NEXT(144$); 


Model  statements  for  module:  BasicProcess. Process  70  (Acquisition  panels  preA) 
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144$  ASSIGN:  Acquisition  panels  preA.Numberln=Acquisition  panels  preA.Numberln  +  1: 

Acquisition  panels  preA.WIP=Acquisition  panels  preA.WIP+1; 

1066$  DELAY:  Triangular(15,30,35)„VA; 

1113$  ASSIGN:  Acquisition  panels  preA.NumberOut=Acquisition  panels  preA.NumberOut  +  1: 

Acquisition  panels  preA.WIP=Acquisition  panels  preA.WIP-l:NEXT(145$); 


;  Model  statements  for  module:  BasicProcess. Decide  58  (Concept  Decision  and  ADM) 

/ 

145$  BRANCH,  1: 

With, (99)/100, 1116$, Yes: 

Else, 1117$, Yes; 

1116$  ASSIGN:  Concept  Decision  and  ADM.NumberOut  True=Concept  Decision  and 

ADM.NumberOut  True  +  1:NEXT(125$); 

1117$  ASSIGN:  Concept  Decision  and  ADM.NumberOut  False=Concept  Decision  and 

ADM.NumberOut  False  +  1:NEXT(146$); 


;  Model  statements  for  module:  BasicProcess. Decide  52  (Check  for  AoA) 
/ 

125$  BRANCH,  1: 

lf,ACAT  Level==l,140$,Yes: 

If, AoA  flag==l,126$,Yes: 

Else, 655$, Yes; 


;  Model  statements  for  module:  BasicProcess. Separate  28  (Non  AoA  Route) 

/ 

655$  DUPLICATE,  100-0: 

1,1122$,0:NEXT(1121$); 

1121$  ASSIGN:  Non  AoA  Route. NumberOut  Orig=Non  AoA  Route. NumberOut  Orig  + 

1:NEXT(130$); 

1122$  ASSIGN:  Non  AoA  Route. NumberOut  Dup=Non  AoA  Route. NumberOut  Dup  + 

1:NEXT(153$); 
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;  Model  statements  for  module:  BasicProcess. Process  62  (Analysis) 

/ 

130$  ASSIGN:  Analysis.  Numberln=Analysis.  Numberln  +  1: 

Analysis.WIP=Analysis.WIP+l; 

1124$  DELAY:  Triangular(2,7,180)„VA; 

1171$  ASSIGN:  Analysis.  NumberOut=Analysis.  NumberOut  +  1: 

Analysis.  WIP=Analysis.WIP-l:NEXT(150$); 


;  Model  statements  for  module:  BasicProcess. Batch  2  (Wait  until  both  complete  preA) 

/ 

150$  QUEUE,  Wait  until  both  complete  preA. Queue; 

1174$  GROUP,  , Permanent^, Last:NEXT(1175$); 

1175$  ASSIGN:  Wait  until  both  complete  preA.NumberOut=Wait  until  both  complete 

preA. NumberOut  +  1:NEXT(132$); 


;  Model  statements  for  module:  BasicProcess. Process  64  (Choose  and  recommend  a  selected  CoA) 

/ 

132$  ASSIGN:  Choose  and  recommend  a  selected  CoA.Numberln=Choose  and  recommend  a 

selected  CoA. Numberln  +  1: 

Choose  and  recommend  a  selected  CoA.WIP=Choose  and  recommend  a  selected 

CoA.WIP+1; 

1177$  DELAY:  Triangular(30,60,90)„VA; 

1224$  ASSIGN:  Choose  and  recommend  a  selected  CoA.NumberOut=Choose  and  recommend  a 

selected  CoA. NumberOut  +  1: 

Choose  and  recommend  a  selected  CoA.WIP=Choose  and  recommend  a  selected 
CoA.WIP-l:NEXT(133$); 


Model  statements  for  module:  BasicProcess. Decide  54  (Approve  Selected  CoA) 


381 


133$  BRANCH,  1: 

With, (99)/100, 1227$, Yes: 

Else, 1228$, Yes; 

1227$  ASSIGN:  Approve  Selected  CoA.NumberOut  True=Approve  Selected  CoA.NumberOut 

True  +  1:NEXT(156$); 

1228$  ASSIGN:  Approve  Selected  CoA.NumberOut  False=Approve  Selected  CoA.NumberOut 

False  +  1:NEXT(134$); 


Model  statements  for  module:  BasicProcess. Batch  3  (Processes  come  together) 


156$  QUEUE,  Processes  come  together. Queue; 
1229$  GROUP,  , Permanent^, Last:NEXT(1230$); 


1230$  ASSIGN:  Processes  come  together.NumberOut=Processes  come  together. NumberOut  + 

1:NEXT(155$); 


;  Model  statements  for  module:  BasicProcess. Assign  20  (Preferred  System  Concept  Named) 
/ 

155$  ASSIGN:  Preferred  System  Concept=TNOW:NEXT(157$); 


;  Model  statements  for  module:  BasicProcess. Process  73  (Draft  RFP  Preparation  preA) 

/ 

157$  ASSIGN:  Draft  RFP  Preparation  preA.Numberln=Draft  RFP  Preparation  preA.Numberln  +  1: 

Draft  RFP  Preparation  preA.WIP=Draft  RFP  Preparation  preA.WIP+1; 

1232$  DELAY:  Triangular(10,17,20)„VA; 

1279$  ASSIGN:  Draft  RFP  Preparation  preA.NumberOut=Draft  RFP  Preparation  preA.NumberOut 

+  1: 

Draft  RFP  Preparation  preA.WIP=Draft  RFP  Preparation  preA.WIP-l:NEXT(158$); 
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;  Model  statements  for  module:  BasicProcess. Separate  4  (Separate  activities  once  preA) 

/ 

158$  DUPLICATE,  100-0: 

1,1284$,0:NEXT(1283$); 

1283$  ASSIGN:  Separate  activities  once  preA.NumberOut  Orig=Separate  activities  once 

preA.NumberOut  Orig  +  1 

:NEXT(160$); 

1284$  ASSIGN:  Separate  activities  once  preA.NumberOut  Dup=Separate  activities  once 

preA.NumberOut  Dup  +  1 

:NEXT(159$); 


;  Model  statements  for  module:  BasicProcess. Process  74  (RFP  Coordination  Process) 

/ 

160$  ASSIGN:  RFP  Coordination  Process. Numberln=RFP  Coordination  Process. Numberln  +  1: 

RFP  Coordination  Process. WIP=RFP  Coordination  Process. WIP+1; 

1286$  DELAY:  Triangular(25,45,50)„VA; 

1333$  ASSIGN:  RFP  Coordination  Process. NumberOut=RFP  Coordination  Process. NumberOut  + 

1: 

RFP  Coordination  Process. WIP=RFP  Coordination  Process. WIP-1:NEXT(165$); 


;  Model  statements  for  module:  BasicProcess. Batch  4  (Complete  predecessor  activities  preA) 

/ 

165$  QUEUE,  Complete  predecessor  activities  preA. Queue; 

1336$  GROUP,  , Permanent^, Last:NEXT(1337$); 

1337$  ASSIGN:  Complete  predecessor  activities  preA.NumberOut=Complete  predecessor 

activities  preA.NumberOut  +  1 
:NEXT(166$); 


Model  statements  for  module:  BasicProcess. Process  78  (Acquisition  Panels) 
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166$  ASSIGN:  Acquisition  Panels. Numberln=Acquisition  Panels. Numberln  +  1: 

Acquisition  Panels. WIP=Acquisition  Panels. WIP+1; 

1339$  DELAY:  Triangular(15,30,35)„VA; 

1386$  ASSIGN:  Acquisition  Panels. NumberOut=Acquisition  Panels. NumberOut  +  1: 

Acquisition  Panels. WIP=Acquisition  Panels. WIP-1:NEXT(167$); 


;  Model  statements  for  module:  BasicProcess. Decide  61  (MDA  Milestone  approval) 
/ 

167$  BRANCH,  1: 

With, (99)/100, 1389$, Yes: 

Else, 1390$, Yes; 

1389$  ASSIGN:  MDA  Milestone  approval. NumberOut  True=MDA  Milestone 

approval. NumberOut  True  +  1:NEXT(171$); 

1390$  ASSIGN:  MDA  Milestone  approval. NumberOut  False=MDA  Milestone 

approval. NumberOut  False  +  1:NEXT(168$); 


;  Model  statements  for  module:  BasicProcess. Assign  22  (MS  A  decision) 
/ 

171$  ASSIGN:  MS  A  decision  time=TNOW:NEXT(173$); 


;  Model  statements  for  module:  BasicProcess. Separate  6  (Split  flow  for  PreMSB) 

/ 

173$  DUPLICATE,  100-0: 

1,1393$,0:NEXT(1392$); 

1392$  ASSIGN:  Split  flow  for  PreMSB. NumberOut  Orig=Split  flow  for  PreMSB. NumberOut  Orig  + 

1:NEXT(295$); 

1393$  ASSIGN:  Split  flow  for  PreMSB. NumberOut  Dup=Split  flow  for  PreMSB. NumberOut  Dup  + 

1:NEXT(284$); 
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;  Model  statements  for  module:  AdvancedProcess.Hold  1  (Wait  for  Signal  from  Acquisition) 
/ 

295$  SCAN:  contract  start==l:NEXT(172$); 


;  Model  statements  for  module:  BasicProcess. Process  79  (KPP  Development) 

/ 

172$  ASSIGN:  KPP  Development. Numberln=KPP  Development. Numberln  +  1: 

KPP  Development. WIP=KPP  Development. WIP+1; 

1395$  DELAY: 

TRIA(0.65*TD  original  contract  length,  ,72*TD  original  contract  length,  0.75*TD  original 
contract  length),, 

VA; 

1442$  ASSIGN:  KPP  Development. NumberOut=KPP  Development. NumberOut  +  1: 

KPP  Development. WIP=KPP  Development.WIP-l:NEXT(652$); 


;  Model  statements  for  module:  BasicProcess. Assign  146  (Assign  KPP  Development  complete  PreB) 
/ 

652$  ASSIGN:  KPP  Development  signal  PreB=l:NEXT(174$); 


;  Model  statements  for  module:  BasicProcess. Decide  64  (Decision  to  pursue  requirements  PreB) 
/ 

174$  BRANCH,  1: 

With, (98)/100, 1445$, Yes: 

Else, 1446$, Yes; 

1445$  ASSIGN:  Decision  to  pursue  requirements  PreB. NumberOut  True= 

Decision  to  pursue  requirements  PreB. NumberOut  True  +  1:NEXT(179$); 

1446$  ASSIGN:  Decision  to  pursue  requirements  PreB. NumberOut  False= 

Decision  to  pursue  requirements  PreB. NumberOut  False  +  1:NEXT(175$); 


385 


;  Model  statements  for  module:  BasicProcess. Process  82  (Draft  briefing  and  materials  PreB) 

/ 

179$  ASSIGN:  Draft  briefing  and  materials  PreB.Numberln=Draft  briefing  and  materials 

PreB.Numberln  +  1: 

Draft  briefing  and  materials  PreB.WIP=Draft  briefing  and  materials  PreB.WIP+1; 
1448$  DELAY:  Triangular(10,31,40)„VA; 

1495$  ASSIGN:  Draft  briefing  and  materials  PreB.NumberOut=Draft  briefing  and  materials 

PreB.NumberOut  +  1: 

Draft  briefing  and  materials  PreB.WIP=Draft  briefing  and  materials  PreB.WIP- 

1:NEXT(180$); 


;  Model  statements  for  module:  BasicProcess. Decide  66  (MAJCOM  A  Letters  Coordinate  and  Concur 
PreB) 

/ 

180$  BRANCH,  1: 

With, (90)/100, 1498$, Yes: 

Else, 1499$, Yes; 

1498$  ASSIGN:  MAJCOM  A  Letters  Coordinate  and  Concur  PreB.NumberOut  True= 

MAJCOM  A  Letters  Coordinate  and  Concur  PreB.NumberOut  True  +  1:NEXT(181$); 

1499$  ASSIGN:  MAJCOM  A  Letters  Coordinate  and  Concur  PreB.NumberOut  False= 

MAJCOM  A  Letters  Coordinate  and  Concur  PreB.NumberOut  False  +  1:NEXT(187$); 


;  Model  statements  for  module:  BasicProcess. Process  87  (Update  and  Schedule  Calendar  PreB) 

/ 

181$  ASSIGN:  Update  and  Schedule  Calendar  PreB.Numberln=Update  and  Schedule  Calendar 

PreB.Numberln  +  1: 

Update  and  Schedule  Calendar  PreB.WIP=Update  and  Schedule  Calendar  PreB.WIP+1; 
1501$  DELAY:  Triangular(3,12,15)„NVA; 

1548$  ASSIGN:  Update  and  Schedule  Calendar  PreB.NumberOut=Update  and  Schedule  Calendar 

PreB.NumberOut  +  1: 

Update  and  Schedule  Calendar  PreB.WIP=Update  and  Schedule  Calendar  PreB.WIP- 

1:NEXT(182$); 
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Model  statements  for  module:  BasicProcess. Decide  69  (PreRSR  MAJCOM  A8  PreB) 


182$  BRANCH,  1: 

With, (99)/100, 1551$, Yes: 

Else, 1552$, Yes; 

1551$  ASSIGN:  PreRSR  MAJCOM  A8  PreB.NumberOut  True=PreRSR  MAJCOM  A8 

PreB.NumberOut  True  +  1:NEXT(183$); 

1552$  ASSIGN:  PreRSR  MAJCOM  A8  PreB.NumberOut  False=PreRSR  MAJCOM  A8 

PreB.NumberOut  False  +  1:NEXT(187$); 


;  Model  statements  for  module:  BasicProcess. Process  88  (Finalize  RSR  and  calendar  items  PreB) 

/ 

183$  ASSIGN:  Finalize  RSR  and  calendar  items  PreB.Numberln=Finalize  RSR  and  calendar  items 

PreB.Numberln  +  1: 

Finalize  RSR  and  calendar  items  PreB.WIP=Finalize  RSR  and  calendar  items  PreB.WIP+1; 
1554$  DELAY:  Triangular(21,28,35)„NVA; 

1601$  ASSIGN:  Finalize  RSR  and  calendar  items  PreB.NumberOut=Finalize  RSR  and  calendar 

items  PreB.NumberOut  +  1: 

Finalize  RSR  and  calendar  items  PreB.WIP=Finalize  RSR  and  calendar  items  PreB.WIP- 

1:NEXT(184$); 


;  Model  statements  for  module:  BasicProcess. Decide  70  (RSR  HQ  USAF  A5R  PreB) 

/ 

184$  BRANCH,  1: 

With, (98)/100, 1604$, Yes: 

Else, 1605$, Yes; 

1604$  ASSIGN:  RSR  HQ  USAF  A5R  PreB.NumberOut  True=RSR  HQ  USAF  A5R  PreB.NumberOut 

True  +  1:NEXT(338$); 

1605$  ASSIGN:  RSR  HQ  USAF  A5R  PreB.NumberOut  False=RSR  HQ  USAF  A5R  PreB.NumberOut 

False  +  1:NEXT(187$); 
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Model  statements  for  module:  AdvancedProcess.Hold  2  (Wait  for  EOA  completion) 


338$  QUEUE,  Wait  for  EOA  completion. Queue; 

SCAN:  EOA  Success==l:NEXT(189$); 


;  Model  statements  for  module:  BasicProcess. Process  90  (Form  High  Performance  Team  PreB) 

/ 

189$  ASSIGN:  Form  High  Performance  Team  PreB.Numberln=Form  High  Performance  Team 

PreB.Numberln  +  1: 

Form  High  Performance  Team  PreB.WIP=Form  High  Performance  Team  PreB.WIP+1; 
1607$  DELAY:  Triangular(30, 41,45),,  Wait; 

1654$  ASSIGN:  Form  High  Performance  Team  PreB.NumberOut=Form  High  Performance  Team 

PreB.NumberOut  +  1: 

Form  High  Performance  Team  PreB.WIP=Form  High  Performance  Team  PreB.WIP- 

1:NEXT(190$); 


;  Model  statements  for  module:  BasicProcess. Process  91  (High  Performance  Team  work  preB) 

/ 

190$  ASSIGN:  High  Performance  Team  work  preB.Numberln=High  Performance  Team  work 

preB.Numberln  + 1: 

High  Performance  Team  work  preB.WIP=High  Performance  Team  work  preB.WIP+1; 
1658$  DELAY:  Triangular(5,6,7)„VA; 

1705$  ASSIGN:  High  Performance  Team  work  preB.NumberOut=High  Performance  Team  work 

preB.NumberOut  +  1: 

High  Performance  Team  work  preB.WIP=High  Performance  Team  work  preB.WIP- 

1:NEXT(380$); 


Model  statements  for  module:  BasicProcess. Assign  76  (Declare  KPPs  ready  for  Acquisition  PreB) 
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380$  ASSIGN:  KPPs  Ready  PreB=l:NEXT(191$); 


;  Model  statements  for  module:  BasicProcess. Decide  74  (Determine  document  approval  path  preB) 
/ 

191$  BRANCH,  1: 

lf,ACAT  Level==3,248$,Yes: 
lf,ACAT  Level==2,222$,Yes: 

Else, 192$, Yes; 


;  Model  statements  for  module:  BasicProcess. Process  92  (Joint  Interest  preB) 

/ 

192$  ASSIGN:  Joint  Interest  preB.Numberln=Joint  Interest  preB.Numberln  +  1: 

Joint  Interest  preB.WIP=Joint  Interest  preB.WIP+l:NEXT(193$); 

193$  ASSIGN:  draft  document  preB  joint  interest. Numberln=draft  document  preB  joint 

interest. Numberln  +  1: 

draft  document  preB  joint  interest. WIP=draft  document  preB  joint  interest. WIP+1; 
1762$  DELAY:  Triangular(30,55,60)„VA; 

1809$  ASSIGN:  draft  document  preB  joint  interest. NumberOut=draft  document  preB  joint 

interest. NumberOut  +  1: 

draft  document  preB  joint  interest. WIP=draft  document  preB  joint  interest. WIP- 

1:NEXT(194$); 

194$  ASSIGN:  Air  Staff  processes  joint  int  preB.Numberln=Air  Staff  processes  joint  int 

preB.Numberln  +  1: 

Air  Staff  processes  joint  int  preB.WIP=Air  Staff  processes  joint  int  preB. WIP+1; 
1813$  DELAY:  Triangular(21,25,42)„VA; 

1860$  ASSIGN:  Air  Staff  processes  joint  int  preB.NumberOut=Air  Staff  processes  joint  int 

preB. NumberOut  +  1: 

Air  Staff  processes  joint  int  preB.WIP=Air  Staff  processes  joint  int  preB.WIP- 

1:NEXT(195$); 

195$  BRANCH,  1: 

With, (95)/100, 1863$, Yes: 

Else,  1864$,  Yes; 

1863$  ASSIGN:  Critical  Comments?  joint  int  preB. NumberOut  True= 

Critical  Comments?  joint  int  preB. NumberOut  True  +  1:NEXT(196$); 
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1864$  ASSIGN:  Critical  Comments?  joint  int  preB.NumberOut  False= 

Critical  Comments?  joint  int  preB.NumberOut  False  +  1:NEXT(199$); 

196$  ASSIGN:  Comment  Resolution  joint  int  preB.Numberln=Comment  Resolution  joint  int 

preB.Numberln  +  1: 

Comment  Resolution  joint  int  preB.WIP=Comment  Resolution  joint  int  preB.WIP+1; 
1866$  DELAY:  Triangular(15,30,45)„VA; 

1913$  ASSIGN:  Comment  Resolution  joint  int  preB.NumberOut=Comment  Resolution  joint  int 

preB.NumberOut  +  1: 

Comment  Resolution  joint  int  preB.WIP=Comment  Resolution  joint  int  preB.WIP- 

1:NEXT(197$); 

197$  BRANCH,  1: 

With, (99)/100, 1916$, Yes: 

Else, 1917$, Yes; 

1916$  ASSIGN:  MAJCOM  Approval?  joint  int  preB.NumberOut  True=MAJCOM  Approval?  joint 

int  preB.NumberOut  True  +  1 
:NEXT(199$); 

1917$  ASSIGN:  MAJCOM  Approval?  joint  int  preB.NumberOut  False=MAJCOM  Approval?  joint 

int  preB.NumberOut  False  +  1 
:NEXT(198$); 

199$  ASSIGN:  AFROC  Preparations  joint  int  preB.Numberln=AFROC  Preparations  joint  int 

preB.Numberln  + 1: 

AFROC  Preparations  joint  int  preB.WIP=AFROC  Preparations  joint  int  preB.WIP+1; 
1919$  DELAY:  Triangular(30,45,60)„VA; 

1966$  ASSIGN:  AFROC  Preparations  joint  int  preB.NumberOut=AFROC  Preparations  joint  int 

preB.NumberOut  +  1: 

AFROC  Preparations  joint  int  preB.WIP=AFROC  Preparations  joint  int  preB.WIP- 

1:NEXT(200$); 

200$  BRANCH,  1: 

With, (90)/100, 1969$, Yes: 

Else, 1970$, Yes; 

1969$  ASSIGN:  AFROC  Decision  joint  int  preB.NumberOut  True=AFROC  Decision  joint  int 

preB.NumberOut  True  +  1 

:NEXT(201$); 

1970$  ASSIGN:  AFROC  Decision  joint  int  preB.NumberOut  False=AFROC  Decision  joint  int 

preB.NumberOut  False  +  1 
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:NEXT(205$); 


201$  BRANCH,  1: 

With, (25)/100, 1971$, Yes: 

Else, 1972$, Yes; 

1971$  ASSIGN:  Post  AFROC  actions  joint  int  preB.NumberOut  True= 

Post  AFROC  actions  joint  int  preB.NumberOut  True  +  1:NEXT(206$); 

1972$  ASSIGN:  Post  AFROC  actions  joint  int  preB.NumberOut  False= 

Post  AFROC  actions  joint  int  preB.NumberOut  False  +  1:NEXT(207$); 

206$  ASSIGN:  Post  AFROC  actions  PreB.Numberln=Post  AFROC  actions  PreB.Numberln  +  1: 

Post  AFROC  actions  PreB.WIP=Post  AFROC  actions  PreB.WIP+1; 

1974$  DELAY:  Triangular(l,ll,15)„VA; 

2021$  ASSIGN:  Post  AFROC  actions  PreB.NumberOut=Post  AFROC  actions  PreB.NumberOut  +  1: 

Post  AFROC  actions  PreB.WIP=Post  AFROC  actions  PreB.WIP-l:NEXT(207$); 

207$  BRANCH,  1: 

With, (50)/100, 2024$, Yes: 

Else, 2025$, Yes; 

2024$  ASSIGN:  Document  Review  Phase  PreB.NumberOut  True=Document  Review  Phase 

PreB.NumberOut  True  +  1:NEXT(208$); 

2025$  ASSIGN:  Document  Review  Phase  PreB.NumberOut  False=Document  Review  Phase 

PreB.NumberOut  False  +  1 

:NEXT(212$); 

208$  ASSIGN:  Document  Reveiw  Phase  2  Flag  Level  PreB.Numberln= 

Document  Reveiw  Phase  2  Flag  Level  PreB.Numberln  +  1: 

Document  Reveiw  Phase  2  Flag  Level  PreB.WIP=Document  Reveiw  Phase  2  Flag  Level 

PreB.WIP+1; 

2027$  DELAY:  Triangular(21,38,42)„VA; 

2074$  ASSIGN:  Document  Reveiw  Phase  2  Flag  Level  PreB.NumberOut= 

Document  Reveiw  Phase  2  Flag  Level  PreB.NumberOut  +  1: 

Document  Reveiw  Phase  2  Flag  Level  PreB.WIP=Document  Reveiw  Phase  2  Flag  Level 

PreB.WIP-1 

:NEXT(209$); 

209$  ASSIGN:  Resolving  Flag  level  comments  PreB.Numberln=Resolving  Flag  level  comments 

PreB.Numberln  +  1: 

Resolving  Flag  level  comments  PreB.WIP=Resolving  Flag  level  comments  PreB.WIP+1; 
2078$  DELAY:  Triangular(15,27,30)„VA; 
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2125$  ASSIGN:  Resolving  Flag  level  comments  PreB.NumberOut=Resolving  Flag  level  comments 

PreB.NumberOut  +  1: 

Resolving  Flag  level  comments  PreB.WIP=Resolving  Flag  level  comments  PreB.WIP- 

1:NEXT(210$); 

210$  BRANCH,  1: 

With, (99)/100, 2128$, Yes: 

Else, 2129$, Yes; 

2128$  ASSIGN:  MAJCOM  approval  PreB.NumberOut  True=MAJCOM  approval  PreB.NumberOut 

True  +  1:NEXT(212$); 

2129$  ASSIGN:  MAJCOM  approval  PreB.NumberOut  False=MAJCOM  approval  PreB.NumberOut 

False  +  1:NEXT(211$); 

212$  ASSIGN:  Functional  Capabilities  Board  PreB.Numberln=Functional  Capabilities  Board 

PreB.Numberln  +  1: 

Functional  Capabilities  Board  PreB.WIP=Functional  Capabilities  Board  PreB.WIP+1; 
2131$  DELAY:  Triangular(7,14,21)„VA; 

2178$  ASSIGN:  Functional  Capabilities  Board  PreB.NumberOut=Functional  Capabilities  Board 

PreB.NumberOut  +  1: 

Functional  Capabilities  Board  PreB.WIP=Functional  Capabilities  Board  PreB.WIP- 

1:NEXT(213$); 

213$  ASSIGN:  Joint  Capabilities  Board  PreB.Numberln=Joint  Capabilities  Board  PreB.Numberln 

+  1: 

Joint  Capabilities  Board  PreB.WIP=Joint  Capabilities  Board  PreB.WIP+1; 

2182$  DELAY:  Triangular(7,14,21)„VA; 

2229$  ASSIGN:  Joint  Capabilities  Board  PreB.NumberOut=Joint  Capabilities  Board 

PreB.NumberOut  +  1: 

Joint  Capabilities  Board  PreB.WIP=Joint  Capabilities  Board  PreB.WIP-l:NEXT(214$); 

214$  BRANCH,  1: 

With, (15)/100, 2232$, Yes: 

Else, 2233$, Yes; 

2232$  ASSIGN:  JCB  issues  PreB.NumberOut  True=JCB  issues  PreB.NumberOut  True  + 

1:NEXT(215$); 

2233$  ASSIGN:  JCB  issues  PreB.NumberOut  False=JCB  issues  PreB.NumberOut  False  + 

1:NEXT(216$); 

215$  ASSIGN:  Resolve  JCB  issues  PreB.Numberln=Resolve  JCB  issues  PreB.Numberln  +  1: 

Resolve  JCB  issues  PreB.WIP=Resolve  JCB  issues  PreB.WIP+1; 
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2235$  DELAY:  Triangular(10,15,20)„VA; 

2282$  ASSIGN:  Resolve  JCB  issues  PreB.NumberOut=Resolve  JCB  issues  PreB.NumberOut  +  1: 

Resolve  JCB  issues  PreB.WIP=Resolve  JCB  issues  PreB.WIP-l:NEXT(216$); 

216$  ASSIGN:  JROC  preparations  PreB.Numberln=JROC  preparations  PreB.Numberln  +  1: 

JROC  preparations  PreB.WIP=JROC  preparations  PreB.WIP+1; 

2286$  DELAY:  Triangular(14,25,30)„VA; 

2333$  ASSIGN:  JROC  preparations  PreB.NumberOut=JROC  preparations  PreB.NumberOut  +  1: 

JROC  preparations  PreB.WIP=JROC  preparations  PreB.WIP-l:NEXT(217$); 

217$  BRANCH,  1: 

With, (98)/100, 2336$, Yes: 

Else, 2337$, Yes; 

2336$  ASSIGN:  JROC  PreB.NumberOut  True=JROC  PreB.NumberOut  True  +  1:NEXT(1758$); 

2337$  ASSIGN:  JROC  PreB.NumberOut  False=JROC  PreB.NumberOut  False  +  1:NEXT(218$); 

218$  ASSIGN:  Resolve  JROC  issues  PreB.Numberln=Resolve  JROC  issues  PreB.Numberln  +  1: 

Resolve  JROC  issues  PreB.WIP=Resolve  JROC  issues  PreB.WIP+1; 

2339$  DELAY:  Triangular(42,51,60)„VA; 

2386$  ASSIGN:  Resolve  JROC  issues  PreB.NumberOut=Resolve  JROC  issues  PreB.NumberOut  +  1: 

Resolve  JROC  issues  PreB.WIP=Resolve  JROC  issues  PreB.WIP-l:NEXT(1758$); 

211$  ASSIGN:  Hold  for  a  year  later  in  process  PreB.Numberln=Hold  for  a  year  later  in  process 

PreB.Numberln  +  1: 

Hold  for  a  year  later  in  process  PreB.WIP=Hold  for  a  year  later  in  process  PreB.WIP+1; 
2390$  DELAY:  Triangular(270,300,365)„NVA; 

2437$  ASSIGN:  Hold  for  a  year  later  in  process  PreB.NumberOut=Hold  for  a  year  later  in  process 

PreB.NumberOut  +  1: 

Hold  for  a  year  later  in  process  PreB.WIP=Hold  for  a  year  later  in  process  PreB.WIP- 

1:NEXT(212$); 

205$  BRANCH,  1: 

lf,AFROC  Count==l, 2440$, Yes: 

Else, 2441$, Yes; 

2440$  ASSIGN:  Check  for  previous  path  joint  int  preB.NumberOut  True= 

Check  for  previous  path  joint  int  preB.NumberOut  True  +  1:NEXT(219$); 

2441$  ASSIGN:  Check  for  previous  path  joint  int  preB.NumberOut  False= 

Check  for  previous  path  joint  int  preB.NumberOut  False  +  1:NEXT(204$); 

219$  ASSIGN:  Kill  time  at  AFROC  joint  interest  preB=TNOW: 
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TFIN=TNOW:NEXT(220$); 


220$  TALLY:  Record  21, INT(SimTime),l:NEXT(203$); 

203$  ASSIGN:  Death  at  AFROC  joint  int  preB.NumberOut=Death  at  AFROC  joint  int 

preB.NumberOut  +  1; 

2442$  DISPOSE:  Yes; 

204$  ASSIGN:  AFROC  Count  PreB=l:NEXT(202$); 

202$  BRANCH,  1: 

With, (99)/100, 2443$, Yes: 

Else, 2444$, Yes; 

2443$  ASSIGN:  Dead  activity  joint  int  preB.NumberOut  True=Dead  activity  joint  int 

preB.NumberOut  True  +  1 

:NEXT(219$); 

2444$  ASSIGN:  Dead  activity  joint  int  preB.NumberOut  False=Dead  activity  joint  int 

preB.NumberOut  False  +  1 

:NEXT(196$); 

198$  ASSIGN:  Hold  for  a  year  PreB.Numberln=Hold  for  a  year  PreB.Numberln  +  1: 

Hold  for  a  year  PreB.WIP=Hold  for  a  year  PreB.WIP+1; 

2446$  DELAY:  Triangular(270,300,365)„NVA; 

2493$  ASSIGN:  Hold  for  a  year  PreB.NumberOut=Hold  for  a  year  PreB.NumberOut  +  1: 

Hold  for  a  year  PreB.WIP=Hold  for  a  year  PreB.WIP-l:NEXT(199$); 

1758$  ASSIGN:  Joint  Interest  preB.NumberOut=Joint  Interest  preB.NumberOut  +  1: 

Joint  Interest  preB.WIP=Joint  Interest  preB.WIP-l:NEXT(221$); 


;  Model  statements  for  module:  BasicProcess. Assign  27  (Record  CCD) 
/ 

221$  ASSIGN:  CCD=1: 

CCD  Time=TNOW:NEXT(353$); 


Model  statements  for  module:  BasicProcess. Batch  14  (Receipt  of  approved  CCD) 
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353$ 

2496$ 


QUEUE, 

GROUP, 


Receipt  of  approved  CCD. Queue; 

, Permanent^, Last:NEXT(2497$); 


2497$  ASSIGN:  Receipt  of  approved  CCD.NumberOut=Receipt  of  approved  CCD.NumberOut  + 

1:NEXT(279$); 


;  Model  statements  for  module:  BasicProcess. Decide  112  (MDA  Milestone  approval  PreB) 

/ 

279$  BRANCH,  1: 

With, (99)/100, 2498$, Yes: 

Else, 2499$, Yes; 

2498$  ASSIGN:  MDA  Milestone  approval  PreB.NumberOut  True=MDA  Milestone  approval 

PreB.NumberOut  True  +  1 

:NEXT(283$); 

2499$  ASSIGN:  MDA  Milestone  approval  PreB.NumberOut  False=MDA  Milestone  approval 

PreB.NumberOut  False  +  1 

:NEXT(280$); 


;  Model  statements  for  module:  BasicProcess. Assign  38  (MS  B  decision) 
/ 

283$  ASSIGN:  MS  B  decision  time=TNOW:NEXT(387$); 


;  Model  statements  for  module:  BasicProcess. Separate  20  (Split  flow  for  PreMS  C) 

/ 

387$  DUPLICATE,  100-0: 

1,2502$, 0:NEXT(2501$); 

2501$  ASSIGN:  Split  flow  for  PreMS  C.NumberOut  Orig=Split  flow  for  PreMS  C.NumberOut  Orig 

+  1:NEXT(512$); 
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2502$  ASSIGN:  Split  flow  for  PreMS  C.NumberOut  Dup=Split  flow  for  PreMS  C.NumberOut  Dup 

+  1:NEXT(574$); 


;  Model  statements  for  module:  AdvancedProcess.Hold  9  (Wait  for  Signal  from  Acquisition  PreC) 
/ 

512$  SCAN:  contract  start  PreC==l:NEXT(386$); 


;  Model  statements  for  module:  BasicProcess. Process  178  (Prepare  Concept  of  Operation) 

/ 

386$  ASSIGN:  Prepare  Concept  of  Operation. Numberln=Prepare  Concept  of 

Operation.  Numberln  +  1: 

Prepare  Concept  of  Operation. WIP=Prepare  Concept  of  Operation. WIP+1; 

2504$  DELAY: 

TRIA(0.6*SDD  original  contract  length,  0.7*SDD  original  contract  length,  0.8*SDD 
original  contract  length),, 

VA; 

2551$  ASSIGN:  Prepare  Concept  of  Operation. NumberOut=Prepare  Concept  of 

Operation. NumberOut  +  1: 

Prepare  Concept  of  Operation. WIP=Prepare  Concept  of  Operation. WIP-1:NEXT(388$); 


;  Model  statements  for  module:  BasicProcess. Decide  146  (Decision  to  pursue  requirements  PreC) 
/ 

388$  BRANCH,  1: 

With, (98)/100, 2554$, Yes: 

Else, 2555$, Yes; 

2554$  ASSIGN:  Decision  to  pursue  requirements  PreC. NumberOut  True= 

Decision  to  pursue  requirements  PreC. NumberOut  True  +  1:NEXT(393$); 

2555$  ASSIGN:  Decision  to  pursue  requirements  PreC. NumberOut  False= 

Decision  to  pursue  requirements  PreC. NumberOut  False  +  1:NEXT(389$); 
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;  Model  statements  for  module:  BasicProcess. Process  180  (Draft  briefing  and  materials  PreC) 

/ 

393$  ASSIGN:  Draft  briefing  and  materials  PreC.Numberln=Draft  briefing  and  materials 

PreC.Numberln  +  1: 

Draft  briefing  and  materials  PreC.WIP=Draft  briefing  and  materials  PreC.WIP+1; 
2557$  DELAY:  Triangular(10,31,40)„VA; 

2604$  ASSIGN:  Draft  briefing  and  materials  PreC.NumberOut=Draft  briefing  and  materials 

PreC.NumberOut  +  1: 

Draft  briefing  and  materials  PreC.WIP=Draft  briefing  and  materials  PreC.WIP- 

1:NEXT(394$); 


;  Model  statements  for  module:  BasicProcess. Decide  148  (MAJCOM  A  Letters  Coordinate  and  Concur 
PreC) 

/ 

394$  BRANCH,  1: 

With, (90)/100, 2607$, Yes: 

Else, 2608$, Yes; 

2607$  ASSIGN:  MAJCOM  A  Letters  Coordinate  and  Concur  PreC.NumberOut  True= 

MAJCOM  A  Letters  Coordinate  and  Concur  PreC.NumberOut  True  +  1:NEXT(395$); 

2608$  ASSIGN:  MAJCOM  A  Letters  Coordinate  and  Concur  PreC.NumberOut  False= 

MAJCOM  A  Letters  Coordinate  and  Concur  PreC.NumberOut  False  +  1:NEXT(401$); 


;  Model  statements  for  module:  BasicProcess. Process  181  (Update  and  Schedule  Calendar  PreC) 

/ 

395$  ASSIGN:  Update  and  Schedule  Calendar  PreC.Numberln=Update  and  Schedule  Calendar 

PreC.Numberln  +  1: 

Update  and  Schedule  Calendar  PreC.WIP=Update  and  Schedule  Calendar  PreC.WIP+1; 
2610$  DELAY:  Triangular(3,12,15)„NVA; 

2657$  ASSIGN:  Update  and  Schedule  Calendar  PreC.NumberOut=Update  and  Schedule  Calendar 

PreC.NumberOut  +  1: 

Update  and  Schedule  Calendar  PreC.WIP=Update  and  Schedule  Calendar  PreC.WIP- 

1:NEXT(396$); 
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Model  statements  for  module:  BasicProcess. Decide  149  (PreRSR  MAJCOM  A8  PreC) 


396$  BRANCH,  1: 

With, (99)/100, 2660$, Yes: 

Else, 2661$, Yes; 

2660$  ASSIGN:  PreRSR  MAJCOM  A8  PreC.NumberOut  True=PreRSR  MAJCOM  A8 

PreC.NumberOut  True  +  1:NEXT(397$); 

2661$  ASSIGN:  PreRSR  MAJCOM  A8  PreC.NumberOut  False=PreRSR  MAJCOM  A8 

PreC.NumberOut  False  +  1:NEXT(401$); 


;  Model  statements  for  module:  BasicProcess. Process  182  (Finalize  RSR  and  calendar  items  PreC) 

/ 

397$  ASSIGN:  Finalize  RSR  and  calendar  items  PreC.Numberln=Finalize  RSR  and  calendar  items 

PreC.Numberln  +  1: 

Finalize  RSR  and  calendar  items  PreC.WIP=Finalize  RSR  and  calendar  items  PreC.WIP+1; 
2663$  DELAY:  Triangular(21,28,35)„NVA; 

2710$  ASSIGN:  Finalize  RSR  and  calendar  items  PreC.NumberOut=Finalize  RSR  and  calendar 

items  PreC.NumberOut  +  1: 

Finalize  RSR  and  calendar  items  PreC.WIP=Finalize  RSR  and  calendar  items  PreC.WIP- 

1:NEXT(398$); 


;  Model  statements  for  module:  BasicProcess. Decide  150  (RSR  HQ  USAF  A5R  PreC) 

/ 

398$  BRANCH,  1: 

With, (98)/100, 2713$, Yes: 

Else, 2714$, Yes; 

2713$  ASSIGN:  RSR  HQ  USAF  A5R  PreC.NumberOut  True=RSR  HQ  USAF  A5R  PreC.NumberOut 

True  +  1:NEXT(403$); 

2714$  ASSIGN:  RSR  HQ  USAF  A5R  PreC.NumberOut  False=RSR  HQ  USAF  A5R  PreC.NumberOut 

False  +  1:NEXT(401$); 
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;  Model  statements  for  module:  BasicProcess. Process  184  (Form  High  Performance  Team  PreC) 

/ 

403$  ASSIGN:  Form  High  Performance  Team  PreC.Numberln=Form  High  Performance  Team 

PreC.Numberln  +  1: 

Form  High  Performance  Team  PreC.WIP=Form  High  Performance  Team  PreC.WIP+1; 
2716$  DELAY:  Triangular(30, 41,45),,  Wait; 

2763$  ASSIGN:  Form  High  Performance  Team  PreC.NumberOut=Form  High  Performance  Team 

PreC.NumberOut  +  1: 

Form  High  Performance  Team  PreC.WIP=Form  High  Performance  Team  PreC.WIP- 

1:NEXT(404$); 


;  Model  statements  for  module:  BasicProcess. Process  185  (High  Performance  Team  work  preC) 

/ 

404$  ASSIGN:  High  Performance  Team  work  preC.Numberln=High  Performance  Team  work 

preC.Numberln  +  1: 

High  Performance  Team  work  preC.WIP=High  Performance  Team  work  preC.WIP+1; 
2767$  DELAY:  Triangular(5,6,7)„VA; 

2814$  ASSIGN:  High  Performance  Team  work  preC.NumberOut=High  Performance  Team  work 

preC.NumberOut  +  1: 

High  Performance  Team  work  preC.WIP=High  Performance  Team  work  preC.WIP- 

1:NEXT(628$); 


;  Model  statements  for  module:  BasicProcess. Assign  127  (Release  KPPs  to  Acquisition  PreC) 
/ 

628$  ASSIGN:  KPPs  Ready  PreC=l:NEXT(405$); 


;  Model  statements  for  module:  BasicProcess. Decide  153  (Determine  document  approval  path  preC) 
/ 

405$  BRANCH,  1: 

lf,ACAT  Level==3,466$,Yes: 
lf,ACAT  Level==2,438$,Yes: 
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Else, 406$, Yes; 


;  Model  statements  for  module:  BasicProcess. Process  186  (Joint  Interest  preC) 

/ 

406$  ASSIGN:  Joint  Interest  preC.Numberln=Joint  Interest  preC.Numberln  +  1: 

Joint  Interest  preC.WIP=Joint  Interest  preC.WIP+l:NEXT(407$); 

407$  ASSIGN:  draft  document  preC  joint  interest. Numberln=draft  document  preC  joint 

interest.  Numberln  +  1: 

draft  document  preC  joint  interest. WIP=draft  document  preC  joint  interest. WIP+1; 
2871$  DELAY:  Triangular(30,55,60)„VA; 

2918$  ASSIGN:  draft  document  preC  joint  interest. N urn berOut=d raft  document  preC  joint 

interest. NumberOut  +  1: 

draft  document  preC  joint  interest. WIP=draft  document  preC  joint  interest. WIP- 

1:NEXT(434$); 

434$  QUEUE,  Wait  for  successful  Design  Readiness  Review  Joint  PreC.Queue; 

SCAN:  DRR  Success==l:NEXT(408$); 

408$  ASSIGN:  Air  Staff  processes  joint  int  preC.Numberln=Air  Staff  processes  joint  int 

preC.Numberln  +  1: 

Air  Staff  processes  joint  int  preC.WIP=Air  Staff  processes  joint  int  preC. WIP+1; 
2922$  DELAY:  Triangular(21,25,42)„VA; 

2969$  ASSIGN:  Air  Staff  processes  joint  int  preC.NumberOut=Air  Staff  processes  joint  int 

preC. NumberOut  +  1: 

Air  Staff  processes  joint  int  preC.WIP=Air  Staff  processes  joint  int  preC.WIP- 

1:NEXT(409$); 

409$  BRANCH,  1: 

With, (95)/100, 2972$, Yes: 

Else, 2973$, Yes; 

2972$  ASSIGN:  Critical  Comments?  joint  int  preC. NumberOut  True= 

Critical  Comments?  joint  int  preC. NumberOut  True  +  1:NEXT(410$); 

2973$  ASSIGN:  Critical  Comments?  joint  int  preC. NumberOut  False= 

Critical  Comments?  joint  int  preC. NumberOut  False  +  1:NEXT(413$); 

410$  ASSIGN:  Comment  Resolution  joint  int  preC.Numberln=Comment  Resolution  joint  int 

preC.Numberln  +  1: 

Comment  Resolution  joint  int  preC.WIP=Comment  Resolution  joint  int  preC. WIP+1; 
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2975$  DELAY:  Triangular(15,30,45)„VA; 

3022$  ASSIGN:  Comment  Resolution  joint  int  preC.NumberOut=Comment  Resolution  joint  int 

preC.NumberOut  +  1: 

Comment  Resolution  joint  int  preC.WIP=Comment  Resolution  joint  int  preC.WIP- 

1:NEXT(411$); 

411$  BRANCH,  1: 

With, (99)/100, 3025$, Yes: 

Else, 3026$, Yes; 

3025$  ASSIGN:  MAJCOM  Approval?  joint  int  preC.NumberOut  True=MAJCOM  Approval?  joint 

int  preC.NumberOut  True  +  1 
:NEXT(413$); 

3026$  ASSIGN:  MAJCOM  Approval?  joint  int  preC.NumberOut  False=MAJCOM  Approval?  joint 

int  preC.NumberOut  False  +  1 
:NEXT(412$); 

413$  ASSIGN:  AFROC  Preparations  joint  int  preC.Numberln=AFROC  Preparations  joint  int 

preC.Numberln  +  1: 

AFROC  Preparations  joint  int  preC.WIP=AFROC  Preparations  joint  int  preC.WIP+1; 
3028$  DELAY:  Triangular(30,45,60)„VA; 

3075$  ASSIGN:  AFROC  Preparations  joint  int  preC.NumberOut=AFROC  Preparations  joint  int 

preC.NumberOut  +  1: 

AFROC  Preparations  joint  int  preC.WIP=AFROC  Preparations  joint  int  preC.WIP- 

1:NEXT(414$); 

414$  BRANCH,  1: 

With, (90)/100, 3078$, Yes: 

Else, 3079$, Yes; 

3078$  ASSIGN:  AFROC  Decision  joint  int  preC.NumberOut  True=AFROC  Decision  joint  int 

preC.NumberOut  True  +  1 

:NEXT(415$); 

3079$  ASSIGN:  AFROC  Decision  joint  int  preC.NumberOut  False=AFROC  Decision  joint  int 

preC.NumberOut  False  + 1 

:NEXT(419$); 

415$  BRANCH,  1: 

With, (25)/100, 3080$, Yes: 

Else, 3081$, Yes; 

3080$  ASSIGN:  Post  AFROC  actions  joint  int  preC.NumberOut  True= 

Post  AFROC  actions  joint  int  preC.NumberOut  True  +  1:NEXT(420$); 
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3081$  ASSIGN:  Post  AFROC  actions  joint  int  preC.NumberOut  False= 

Post  AFROC  actions  joint  int  preC.NumberOut  False  +  1:NEXT(421$); 

420$  ASSIGN:  Post  AFROC  actions  PreC.Numberln=Post  AFROC  actions  PreC.Numberln  +  1: 

Post  AFROC  actions  PreC.WIP=Post  AFROC  actions  PreC.WIP+1; 

3083$  DELAY:  Triangular(l,ll,15)„VA; 

3130$  ASSIGN:  Post  AFROC  actions  PreC.NumberOut=Post  AFROC  actions  PreC.NumberOut  +  1: 

Post  AFROC  actions  PreC.WIP=Post  AFROC  actions  PreC.WIP-l:NEXT(421$); 

421$  BRANCH,  1: 

With, (50)/100, 3133$, Yes: 

Else, 3134$, Yes; 

3133$  ASSIGN:  Document  Review  Phase  PreC.NumberOut  True=Document  Review  Phase 

PreC.NumberOut  True  +  1:NEXT(422$); 

3134$  ASSIGN:  Document  Review  Phase  PreC.NumberOut  False=Document  Review  Phase 

PreC.NumberOut  False  +  1 

:NEXT(426$); 

422$  ASSIGN:  Document  Reveiw  Phase  2  Flag  Level  PreC.Numberln= 

Document  Reveiw  Phase  2  Flag  Level  PreC.Numberln  +  1: 

Document  Reveiw  Phase  2  Flag  Level  PreC.WIP=Document  Reveiw  Phase  2  Flag  Level 

PreC.WIP+1; 

3136$  DELAY:  Triangular(21,38,42)„VA; 

3183$  ASSIGN:  Document  Reveiw  Phase  2  Flag  Level  PreC.NumberOut= 

Document  Reveiw  Phase  2  Flag  Level  PreC.NumberOut  +  1: 

Document  Reveiw  Phase  2  Flag  Level  PreC.WIP=Document  Reveiw  Phase  2  Flag  Level 

PreC.WIP-1 

:NEXT(423$); 

423$  ASSIGN:  Resolving  Flag  level  comments  PreC.Numberln=Resolving  Flag  level  comments 

PreC.Numberln  +  1: 

Resolving  Flag  level  comments  PreC.WIP=Resolving  Flag  level  comments  PreC.WIP+1; 
3187$  DELAY:  Triangular(15,27,30)„VA; 

3234$  ASSIGN:  Resolving  Flag  level  comments  PreC.NumberOut=Resolving  Flag  level  comments 

PreC.NumberOut  +  1: 

Resolving  Flag  level  comments  PreC.WIP=Resolving  Flag  level  comments  PreC.WIP- 

1:NEXT(424$); 

424$  BRANCH,  1: 

With, (99)/100,3237$, Yes: 
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Else, 3238$, Yes; 

3237$  ASSIGN:  MAJCOM  approval  PreC.NumberOut  True=MAJCOM  approval  PreC.NumberOut 

True  +  1:NEXT(426$); 

3238$  ASSIGN:  MAJCOM  approval  PreC.NumberOut  False=MAJCOM  approval  PreC.NumberOut 

False  +  1:NEXT(425$); 

426$  ASSIGN:  Functional  Capabilities  Board  PreC.Numberln=Functional  Capabilities  Board 

PreC.Numberln  +  1: 

Functional  Capabilities  Board  PreC.WIP=Functional  Capabilities  Board  PreC.WIP+1; 
3240$  DELAY:  Triangular(7,14,21)„VA; 

3287$  ASSIGN:  Functional  Capabilities  Board  PreC.NumberOut=Functional  Capabilities  Board 

PreC.NumberOut  +  1: 

Functional  Capabilities  Board  PreC.WIP=Functional  Capabilities  Board  PreC.WIP- 

1:NEXT(427$); 

427$  ASSIGN:  Joint  Capabilities  Board  PreC.Numberln=Joint  Capabilities  Board  PreC.Numberln 

+  1: 

Joint  Capabilities  Board  PreC.WIP=Joint  Capabilities  Board  PreC.WIP+1; 

3291$  DELAY:  Triangular(7,14,21)„VA; 

3338$  ASSIGN:  Joint  Capabilities  Board  PreC.NumberOut=Joint  Capabilities  Board 

PreC.NumberOut  +  1: 

Joint  Capabilities  Board  PreC.WIP=Joint  Capabilities  Board  PreC.WIP-l:NEXT(428$); 

428$  BRANCH,  1: 

With, (15)/100, 3341$, Yes: 

Else, 3342$, Yes; 

3341$  ASSIGN:  JCB  issues  PreC.NumberOut  True=JCB  issues  PreC.NumberOut  True  + 

1:NEXT(429$); 

3342$  ASSIGN:  JCB  issues  PreC.NumberOut  False=JCB  issues  PreC.NumberOut  False  + 

1:NEXT(430$); 

429$  ASSIGN:  Resolve  JCB  issues  PreC.Numberln=Resolve  JCB  issues  PreC.Numberln  +  1: 

Resolve  JCB  issues  PreC.WIP=Resolve  JCB  issues  PreC.WIP+1; 

3344$  DELAY:  Triangular(10,15,20)„VA; 

3391$  ASSIGN:  Resolve  JCB  issues  PreC.NumberOut=Resolve  JCB  issues  PreC.NumberOut  +  1: 

Resolve  JCB  issues  PreC.WIP=Resolve  JCB  issues  PreC.WIP-l:NEXT(430$); 

430$  ASSIGN:  JROC  preparations  PreC.Numberln=JROC  preparations  PreC.Numberln  +  1: 

JROC  preparations  PreC.WIP=JROC  preparations  PreC.WIP+1; 

3395$  DELAY:  Triangular(14,25,30)„VA; 
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3442$  ASSIGN:  JROC  preparations  PreC.NumberOut=JROC  preparations  PreC.NumberOut  +  1: 

JROC  preparations  PreC.WIP=JROC  preparations  PreC.WIP-l:NEXT(431$); 

431$  BRANCH,  1: 

With, (98)/100, 3445$, Yes: 

Else, 3446$, Yes; 

3445$  ASSIGN:  JROC  PreC.NumberOut  True=JROC  PreC.NumberOut  True  +  1:NEXT(2867$); 

3446$  ASSIGN:  JROC  PreC.NumberOut  False=JROC  PreC.NumberOut  False  +  1:NEXT(432$); 

432$  ASSIGN:  Resolve  JROC  issues  PreC.Numberln=Resolve  JROC  issues  PreC.Numberln  +  1: 

Resolve  JROC  issues  PreC.WIP=Resolve  JROC  issues  PreC.WIP+1; 

3448$  DELAY:  Triangular(42,51,60)„VA; 

3495$  ASSIGN:  Resolve  JROC  issues  PreC.NumberOut=Resolve  JROC  issues  PreC.NumberOut  +  1: 

Resolve  JROC  issues  PreC.WIP=Resolve  JROC  issues  PreC.WIP-l:NEXT(2867$); 

425$  ASSIGN:  Hold  for  a  year  later  in  process  PreC.Numberln=Hold  for  a  year  later  in  process 

PreC.Numberln  +  1: 

Hold  for  a  year  later  in  process  PreC.WIP=Hold  for  a  year  later  in  process  PreC.WIP+1; 
3499$  DELAY:  Triangular(270,300,365)„NVA; 

3546$  ASSIGN:  Hold  for  a  year  later  in  process  PreC.NumberOut=Hold  for  a  year  later  in  process 

PreC.NumberOut  +  1: 

Hold  for  a  year  later  in  process  PreC.WIP=Hold  for  a  year  later  in  process  PreC.WIP- 

1:NEXT(426$); 

419$  BRANCH,  1: 

lf,AFROC  Count  PreC==l, 3549$, Yes: 

Else, 3550$, Yes; 

3549$  ASSIGN:  Check  for  previous  path  joint  int  preC.NumberOut  True= 

Check  for  previous  path  joint  int  preC.NumberOut  True  +  1:NEXT(433$); 

3550$  ASSIGN:  Check  for  previous  path  joint  int  preC.NumberOut  False= 

Check  for  previous  path  joint  int  preC.NumberOut  False  +  1:NEXT(418$); 

433$  ASSIGN:  Kill  time  at  AFROC  joint  interest  PreC=TNOW: 

TFIN=TNOW:NEXT(436$); 

436$  TALLY:  Record  24, INT(SimTime),l:NEXT(417$); 

417$  ASSIGN:  Death  at  AFROC  joint  int  preC.NumberOut=Death  at  AFROC  joint  int 

preC.NumberOut  +  1; 

3551$  DISPOSE:  Yes; 
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418$  ASSIGN:  AFROC  Count  PreC=l:NEXT(416$); 

416$  BRANCH,  1: 

With, (99)/100, 3552$, Yes: 

Else, 3553$, Yes; 

3552$  ASSIGN:  Dead  activity  joint  int  preC.NumberOut  True=Dead  activity  joint  int 

preC.NumberOut  True  +  1 

:NEXT(433$); 

3553$  ASSIGN:  Dead  activity  joint  int  preC.NumberOut  False=Dead  activity  joint  int 

preC.NumberOut  False  +  1 

:NEXT(410$); 

412$  ASSIGN:  Hold  for  a  year  PreC.Numberln=Hold  for  a  year  PreC.Numberln  +  1: 

Hold  for  a  year  PreC.WIP=Hold  for  a  year  PreC.WIP+1; 

3555$  DELAY:  Triangular(270,300,365)„NVA; 

3602$  ASSIGN:  Hold  for  a  year  PreC.NumberOut=Hold  for  a  year  PreC.NumberOut  +  1: 

Hold  for  a  year  PreC.WIP=Hold  for  a  year  PreC.WIP-l:NEXT(413$); 

2867$  ASSIGN:  Joint  Interest  preC.NumberOut=Joint  Interest  preC.NumberOut  +  1: 

Joint  Interest  preC.WIP=Joint  Interest  preC.WIP-l:NEXT(437$); 


;  Model  statements  for  module:  BasicProcess. Assign  84  (Record  CPD) 
/ 

437$  ASSIGN:  CPD=1: 

CPD  Time=TNOW:NEXT(553$); 


Model  statements  for  module:  BasicProcess. Batch  19  (Receipt  of  approved  CPD) 


553$  QUEUE,  Receipt  of  approved  CPD. Queue; 
3605$  GROUP,  , Permanent^, Last:NEXT(3606$); 


3606$  ASSIGN:  Receipt  of  approved  CPD.NumberOut=Receipt  of  approved  CPD.NumberOut  + 

1:NEXT(496$); 
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Model  statements  for  module:  BasicProcess. Decide  182  (MDA  Milestone  approval  PreC) 


496$  BRANCH,  1: 

With, (90)/100, 3607$, Yes: 

Else, 3608$, Yes; 

3607$  ASSIGN:  MDA  Milestone  approval  PreC.NumberOut  True=MDA  Milestone  approval 

PreC.NumberOut  True  +  1 

:NEXT(500$); 

3608$  ASSIGN:  MDA  Milestone  approval  PreC.NumberOut  False=MDA  Milestone  approval 

PreC.NumberOut  False  +  1 

:NEXT(497$); 


;  Model  statements  for  module:  BasicProcess. Assign  90  (MS  C  decision) 
/ 

500$  ASSIGN:  MS  C  decision  time=TNOW:NEXT(555$); 


;  Model  statements  for  module:  BasicProcess. Assign  103  (End  simulation) 
/ 

555$  ASSIGN:  TFIN=TNOW:NEXT(671$); 


;  Model  statements  for  module:  BasicProcess. Record  15  (Record  15) 
/ 

671$  TALLY:  Record  15,INT(SimTime),l:NEXT(554$); 


Model  statements  for  module:  BasicProcess. Dispose  40  (End  at  MS  C) 
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554$  ASSIGN:  End  at  MS  C.NumberOut=End  at  MS  C.NumberOut  +  1; 

3609$  DISPOSE:  No; 


;  Model  statements  for  module:  BasicProcess. Decide  183  (Check  for  previous  MDA  decision  attempt 
preC) 

/ 

497$  BRANCH,  1: 

If, MS  C  approval  attempt==l, 3610$, Yes: 

Else, 3611$, Yes; 

3610$  ASSIGN:  Check  for  previous  MDA  decision  attempt  preC.NumberOut  True= 

Check  for  previous  MDA  decision  attempt  preC.NumberOut  True  +  1:NEXT(556$); 

3611$  ASSIGN:  Check  for  previous  MDA  decision  attempt  preC.NumberOut  False= 

Check  for  previous  MDA  decision  attempt  preC.NumberOut  False  +  1:NEXT(499$); 


;  Model  statements  for  module:  BasicProcess. Assign  104  (End  Simulation  PreC  4) 
/ 

556$  ASSIGN:  Kill  time  at  MS  C  decision=TNOW: 

TFIN=TNOW:NEXT(670$); 


;  Model  statements  for  module:  BasicProcess. Record  14  (Record  14) 
/ 

670$  TALLY:  Record  14,INT(SimTime),l:NEXT(498$); 


;  Model  statements  for  module:  BasicProcess. Dispose  38  (Kill  at  MS  C  decision) 

/ 

498$  ASSIGN:  Kill  at  MS  C  decision. NumberOut=Kill  at  MS  C  decision. NumberOut  +  1; 

3612$  DISPOSE:  No; 
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Model  statements  for  module:  BasicProcess. Assign  89  (Assign  counter  to  MDA  loop  preC) 


499$  ASSIGN:  MS  C  approval  attempt=l:NEXT(634$); 


;  Model  statements  for  module:  BasicProcess. Process  272  (Delay  to  repeat  required  steps  PreC) 

/ 

634$  ASSIGN:  Delay  to  repeat  required  steps  PreC.Numberln=Delay  to  repeat  required  steps 

PreC.Numberln  +  1: 

Delay  to  repeat  required  steps  PreC.WIP=Delay  to  repeat  required  steps  PreC.WIP+1; 
3614$  DELAY:  Triangular(60,120,180)„VA; 

3661$  ASSIGN:  Delay  to  repeat  required  steps  PreC.NumberOut=Delay  to  repeat  required  steps 

PreC.NumberOut  +  1: 

Delay  to  repeat  required  steps  PreC.WIP=Delay  to  repeat  required  steps  PreC.WIP- 

1:NEXT(496$); 


;  Model  statements  for  module:  BasicProcess. Process  214  (Independent  document  preC) 

/ 

466$  ASSIGN:  Independent  document  preC.Numberln=lndependent  document  preC.Numberln 

+  1: 

Independent  document  preC.WIP=lndependent  document  preC.WIP+l:NEXT(467$); 

467$  ASSIGN:  Draft  document  indep  preC.Numberln=Draft  document  indep  preC.Numberln  + 

1: 

Draft  document  indep  preC.WIP=Draft  document  indep  preC.WIP+1; 

3716$  DELAY:  Triangular(30,55,60)„VA; 

3763$  ASSIGN:  Draft  document  indep  preC.NumberOut=Draft  document  indep 

preC.NumberOut  +  1: 

Draft  document  indep  preC.WIP=Draft  document  indep  preC.WIP-l:NEXT(482$); 

482$  QUEUE,  Wait  for  successful  Design  Readiness  Review  Indep  PreC. Queue; 

SCAN:  DRR  Success==l:NEXT(468$); 

468$  ASSIGN:  Air  staff  process  indep  preC.Numberln=Air  staff  process  indep  preC.Numberln  + 

1: 
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Air  staff  process  indep  preC.WIP=Air  staff  process  indep  preC.WIP+1; 

3767$  DELAY:  Triangular(21,29,42)„VA; 

3814$  ASSIGN:  Air  staff  process  indep  preC.NumberOut=Air  staff  process  indep 

preC.NumberOut  +  1: 

Air  staff  process  indep  preC.WIP=Air  staff  process  indep  preC.WIP-l:NEXT(469$); 

469$  BRANCH,  1: 

With, (95)/100, 3817$, Yes: 

Else, 3818$, Yes; 

3817$  ASSIGN:  Critical  comments  indep  preC.NumberOut  True=Critical  comments  indep 

preC.NumberOut  True  +  1 

:NEXT(470$); 

3818$  ASSIGN:  Critical  comments  indep  preC.NumberOut  False=Critical  comments  indep 

preC.NumberOut  False  +  1 

:NEXT(473$); 

470$  ASSIGN:  comment  resolution  indep  preC.Numberln=comment  resolution  indep 

preC.Numberln  +  1: 

comment  resolution  indep  preC.WIP=comment  resolution  indep  preC.WIP+1; 
3820$  DELAY:  Triangular(15,30,45)„VA; 

3867$  ASSIGN:  comment  resolution  indep  preC.NumberOut=comment  resolution  indep 

preC.NumberOut  +  1: 

comment  resolution  indep  preC.WIP=comment  resolution  indep  preC.WIP- 

1:NEXT(471$); 

471$  BRANCH,  1: 

With, (99)/100, 3870$, Yes: 

Else, 3871$, Yes; 

3870$  ASSIGN:  MAJCOM  approval  indep  preC.NumberOut  True=MAJCOM  approval  indep 

preC.NumberOut  True  +  1:NEXT(473$); 

3871$  ASSIGN:  MAJCOM  approval  indep  preC.NumberOut  False=MAJCOM  approval  indep 

preC.NumberOut  False  +  1 

:NEXT(472$); 

473$  ASSIGN:  AFROC  Preparations  indep  preC.Numberln=AFROC  Preparations  indep 

preC.Numberln  +  1: 

AFROC  Preparations  indep  preC.WIP=AFROC  Preparations  indep  preC.WIP+1; 
3873$  DELAY:  Triangular(30,45,60)„VA; 

3920$  ASSIGN:  AFROC  Preparations  indep  preC.NumberOut=AFROC  Preparations  indep 

preC.NumberOut  +  1: 
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AFROC  Preparations  indep  preC.WIP=AFROC  Preparations  indep  preC.WIP- 

1:NEXT(474$); 

474$  BRANCH,  1: 

With, (90)/100, 3923$, Yes: 

Else, 3924$, Yes; 

3923$  ASSIGN:  AFROC  decision  indep  preC.NumberOut  True=AFROC  decision  indep 

preC.NumberOut  True  +  1:NEXT(479$); 

3924$  ASSIGN:  AFROC  decision  indep  preC.NumberOut  False=AFROC  decision  indep 

preC.NumberOut  False  +  1:NEXT(478$); 

479$  BRANCH,  1: 

With, (25)/100, 3925$, Yes: 

Else, 3926$, Yes; 

3925$  ASSIGN:  Post  AFROC  actions  indep  preC.NumberOut  True=Post  AFROC  actions  indep 

preC.NumberOut  True  +  1 

:NEXT(480$); 

3926$  ASSIGN:  Post  AFROC  actions  indep  preC.NumberOut  False=Post  AFROC  actions  indep 

preC.NumberOut  False  +  1 

:NEXT(3712$); 

480$  ASSIGN:  Accomplish  Post  AFROC  actions  indep  preC.Numberln= 

Accomplish  Post  AFROC  actions  indep  preC.Numberln  +  1: 

Accomplish  Post  AFROC  actions  indep  preC.WIP=Accomplish  Post  AFROC  actions  indep 

preC.WIP+1; 

3928$  DELAY:  Triangular(l,ll,15)„VA; 

3975$  ASSIGN:  Accomplish  Post  AFROC  actions  indep  preC.NumberOut= 

Accomplish  Post  AFROC  actions  indep  preC.NumberOut  +  1: 

Accomplish  Post  AFROC  actions  indep  preC.WIP=Accomplish  Post  AFROC  actions  indep 

preC.WIP-1 

:NEXT(3712$); 

478$  BRANCH,  1: 

If, AFROC  Count  PreC==l, 3978$, Yes: 

Else, 3979$, Yes; 

3978$  ASSIGN:  Check  for  previous  path  indep  preC.NumberOut  True= 

Check  for  previous  path  indep  preC.NumberOut  True  +  1:NEXT(481$); 

3979$  ASSIGN:  Check  for  previous  path  indep  preC.NumberOut  False= 

Check  for  previous  path  indep  preC.NumberOut  False  +  1:NEXT(477$); 
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481$ 

ASSIGN: 

TFIN: 

Kill  time  at  AFROC  indep  preC=TNOW: 

=TNOW:NEXT(484$); 

484$ 

TALLY: 

Record  26,INT(SimTime),l:NEXT(476$); 

476$ 

+ 1; 

ASSIGN: 

Death  at  AFROC  indep  preC.NumberOut=Death  at  AFROC  indep  preC.NumberOut 

3980$ 

DISPOSE: 

Yes; 

477$ 

ASSIGN: 

AFROC  Count  PreC=l:NEXT(475$); 

475$ 

BRANCH, 

1: 

With, (99)/100, 3981$, Yes: 

Else, 3982$, Yes; 

3981$  ASSIGN:  Dead  activity  indep  preC.NumberOut  True=Dead  activity  indep  preC.NumberOut 

True  +  1:NEXT(481$); 

3982$  ASSIGN:  Dead  activity  indep  preC.NumberOut  False=Dead  activity  indep 

preC.NumberOut  False  +  1:NEXT(470$); 

472$  ASSIGN:  Hold  for  a  year  later  in  process  indep  preC.Numberln= 

Hold  for  a  year  later  in  process  indep  preC.Numberln  +  1: 

Hold  for  a  year  later  in  process  indep  preC.WIP=Hold  for  a  year  later  in  process  indep 

preC.WIP+1; 

3984$  DELAY:  Triangular(270,300,365)„NVA; 

4031$  ASSIGN:  Hold  for  a  year  later  in  process  indep  preC.NumberOut= 

Hold  for  a  year  later  in  process  indep  preC.NumberOut  +  1: 

Hold  for  a  year  later  in  process  indep  preC.WIP=Hold  for  a  year  later  in  process  indep 

preC.WIP-1 

:NEXT(473$); 

3712$  ASSIGN:  Independent  document  preC.NumberOut=lndependent  document 

preC.NumberOut  +  1: 

Independent  document  preC.WIP=lndependent  document  preC.WIP-l:NEXT(437$); 


;  Model  statements  for  module:  BasicProcess. Process  201  (Joint  Integration  PreC) 

/ 

438$  ASSIGN:  Joint  Integration  PreC.Numberln=Joint  Integration  PreC.Numberln  +  1: 
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Joint  Integration  PreC.WIP=Joint  Integration  PreC.WIP+l:NEXT(439$); 


439$  ASSIGN:  Draft  document  joint  integ  preC.Numberln=Draft  document  joint  integ 

preC.Numberln  +  1: 

Draft  document  joint  integ  preC.WIP=Draft  document  joint  integ  preC.WIP+1; 

4086$  DELAY:  Triangular(30,55,60)„VA; 

4133$  ASSIGN:  Draft  document  joint  integ  preC.NumberOut=Draft  document  joint  integ 

preC.NumberOut  +  1: 

Draft  document  joint  integ  preC.WIP=Draft  document  joint  integ  preC.WIP- 

1:NEXT(463$); 

463$  QUEUE,  Wait  for  successful  Design  Readiness  Review  Interest  PreC. Queue; 

SCAN:  DRR  Success==l:NEXT(440$); 

440$  ASSIGN:  Air  staff  process  joint  integ  preC.Numberln=Air  staff  process  joint  integ 

preC.Numberln  +  1: 

Air  staff  process  joint  integ  preC.WIP=Air  staff  process  joint  integ  preC.WIP+1; 

4137$  DELAY:  Triangular(21,29,42)„VA; 

4184$  ASSIGN:  Air  staff  process  joint  integ  preC.NumberOut=Air  staff  process  joint  integ 

preC.NumberOut  +  1: 

Air  staff  process  joint  integ  preC.WIP=Air  staff  process  joint  integ  preC.WIP- 

1:NEXT(441$); 

441$  BRANCH,  1: 

With, (95)/100, 4187$, Yes: 

Else, 4188$, Yes; 

4187$  ASSIGN:  Critical  comments  joint  integ  preC.NumberOut  True= 

Critical  comments  joint  integ  preC.NumberOut  True  +  1:NEXT(442$); 

4188$  ASSIGN:  Critical  comments  joint  integ  preC.NumberOut  False= 

Critical  comments  joint  integ  preC.NumberOut  False  +  1:NEXT(444$); 

442$  ASSIGN:  comment  resolution  joint  integ  preC.Numberln=comment  resolution  joint  integ 

preC.Numberln  +  1: 

comment  resolution  joint  integ  preC.WIP=comment  resolution  joint  integ  preC.WIP+1; 
4190$  DELAY:  Triangular(15,30,45)„VA; 

4237$  ASSIGN:  comment  resolution  joint  integ  preC.NumberOut=comment  resolution  joint 

integ  preC.NumberOut  +  1: 

comment  resolution  joint  integ  preC.WIP=comment  resolution  joint  integ  preC.WIP- 

1:NEXT(443$); 

443$  BRANCH,  1: 
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With, (99)/100, 4240$, Yes: 

Else, 4241$, Yes; 

4240$  ASSIGN:  MAJCOM  approval  joint  integ  preC.NumberOut  True=MAJCOM  approval  joint 

integ  preC.NumberOut  True  +  1 
:NEXT(444$); 

4241$  ASSIGN:  MAJCOM  approval  joint  integ  preC.NumberOut  False= 

MAJCOM  approval  joint  integ  preC.NumberOut  False  +  1:NEXT(450$); 

444$  BRANCH,  1: 

With, (50)/100, 4242$, Yes: 

Else, 4243$, Yes; 

4242$  ASSIGN:  Document  review  phase  joint  integ  preC.NumberOut  True= 

Document  review  phase  joint  integ  preC.NumberOut  True  +  1:NEXT(445$); 

4243$  ASSIGN:  Document  review  phase  joint  integ  preC.NumberOut  False= 

Document  review  phase  joint  integ  preC.NumberOut  False  +  1:NEXT(448$); 

445$  ASSIGN:  Document  review  phase  2  flag  level  joint  integ  preC.Numberln= 

Document  review  phase  2  flag  level  joint  integ  preC.Numberln  +  1: 

Document  review  phase  2  flag  level  joint  integ  preC.WIP= 

Document  review  phase  2  flag  level  joint  integ  preC.WIP+1; 

4245$  DELAY:  Triangular(21,34,42)„VA; 

4292$  ASSIGN:  Document  review  phase  2  flag  level  joint  integ  preC.NumberOut= 

Document  review  phase  2  flag  level  joint  integ  preC.NumberOut  +  1: 

Document  review  phase  2  flag  level  joint  integ  preC.WIP= 

Document  review  phase  2  flag  level  joint  integ  preC.WIP-l:NEXT(446$); 

446$  ASSIGN:  Resolving  flag  level  comments  joint  integ  preC.Numberln= 

Resolving  flag  level  comments  joint  integ  preC.Numberln  +  1: 

Resolving  flag  level  comments  joint  integ  preC.WIP= 

Resolving  flag  level  comments  joint  integ  preC.WIP+1; 

4296$  DELAY:  Triangular(15,28,30)„VA; 

4343$  ASSIGN:  Resolving  flag  level  comments  joint  integ  preC.NumberOut= 

Resolving  flag  level  comments  joint  integ  preC.NumberOut  +  1: 

Resolving  flag  level  comments  joint  integ  preC.WIP= 

Resolving  flag  level  comments  joint  integ  preC.WIP-l:NEXT(447$); 

447$  BRANCH,  1: 

With, (99)/100, 4346$, Yes: 

Else, 4347$, Yes; 

4346$  ASSIGN:  MAJCOM  approval  later  on  joint  integ  preC.NumberOut  True= 
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MAJCOM  approval  later  on  joint  integ  preC.NumberOut  True  +  1:NEXT(448$); 


4347$  ASSIGN:  MAJCOM  approval  later  on  joint  integ  preC.NumberOut  False= 

MAJCOM  approval  later  on  joint  integ  preC.NumberOut  False  +  1:NEXT(451$); 

448$  ASSIGN:  Interoperability  Certification  joint  integ  preC.Numberln= 

Interoperability  Certification  joint  integ  preC.Numberln  +  1: 

Interoperability  Certification  joint  integ  preC.WIP= 

Interoperability  Certification  joint  integ  preC.WIP+1; 

4349$  DELAY:  Triangular(10,15,20)„VA; 

4396$  ASSIGN:  Interoperability  Certification  joint  integ  preC.NumberOut= 

Interoperability  Certification  joint  integ  preC.NumberOut  +  1: 

Interoperability  Certification  joint  integ  preC.WIP= 

Interoperability  Certification  joint  integ  preC.WIP-l:NEXT(449$); 

449$  ASSIGN:  AFROC  Preparations  joint  integ  preC.Numberln=AFROC  Preparations  joint  integ 

preC.Numberln  +  1: 

AFROC  Preparations  joint  integ  preC.WIP=AFROC  Preparations  joint  integ  preC.WIP+1; 
4400$  DELAY:  Triangular(30,45,60)„VA; 

4447$  ASSIGN:  AFROC  Preparations  joint  integ  preC.NumberOut=AFROC  Preparations  joint 

integ  preC.NumberOut  +  1: 

AFROC  Preparations  joint  integ  preC.WIP=AFROC  Preparations  joint  integ  preC.WIP- 

1:NEXT(452$); 

452$  BRANCH,  1: 

With, (90)/100, 4450$, Yes: 

Else, 4451$, Yes; 

4450$  ASSIGN:  AFROC  decision  joint  integ  preC.NumberOut  True=AFROC  decision  joint  integ 

preC.NumberOut  True  +  1 

:NEXT(457$); 

4451$  ASSIGN:  AFROC  decision  joint  integ  preC.NumberOut  False=AFROC  decision  joint  integ 

preC.NumberOut  False  +  1 

:NEXT(456$); 

457$  BRANCH,  1: 

With, (25)/100, 4452$, Yes: 

Else, 4453$, Yes; 

4452$  ASSIGN:  Post  AFROC  actions  joint  integ  preC.NumberOut  True= 

Post  AFROC  actions  joint  integ  preC.NumberOut  True  +  1:NEXT(458$); 

4453$  ASSIGN:  Post  AFROC  actions  joint  integ  preC.NumberOut  False= 
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Post  AFROC  actions  joint  integ  preC.NumberOut  False  +  1:NEXT(459$); 


458$  ASSIGN:  Accomplish  Post  AFROC  actions  joint  integ  preC.Numberln= 

Accomplish  Post  AFROC  actions  joint  integ  preC.Numberln  +  1: 

Accomplish  Post  AFROC  actions  joint  integ  preC.WIP= 

Accomplish  Post  AFROC  actions  joint  integ  preC.WIP+1; 

4455$  DELAY:  Triangular(l,ll,15)„VA; 

4502$  ASSIGN:  Accomplish  Post  AFROC  actions  joint  integ  preC.NumberOut= 

Accomplish  Post  AFROC  actions  joint  integ  preC.NumberOut  +  1: 

Accomplish  Post  AFROC  actions  joint  integ  preC.WIP= 

Accomplish  Post  AFROC  actions  joint  integ  preC.WIP-l:NEXT(459$); 

459$  ASSIGN:  document  signing  and  validation  joint  integ  preC.Numberln= 

document  signing  and  validation  joint  integ  preC.Numberln  +  1: 
document  signing  and  validation  joint  integ  preC.WIP= 
document  signing  and  validation  joint  integ  preC.WIP+1; 

4506$  DELAY:  Triangular(14,26,30)„VA; 

4553$  ASSIGN:  document  signing  and  validation  joint  integ  preC.NumberOut= 

document  signing  and  validation  joint  integ  preC.NumberOut  +  1: 
document  signing  and  validation  joint  integ  preC.WIP= 
document  signing  and  validation  joint  integ  preC.WIP-l:NEXT(460$); 

460$  BRANCH,  1: 

With, (99)/100, 4556$, Yes: 

Else, 4557$, Yes; 

4556$  ASSIGN:  Final  AFROC  approval  joint  integ  preC.NumberOut  True= 

Final  AFROC  approval  joint  integ  preC.NumberOut  True  +  1:NEXT(4082$); 

4557$  ASSIGN:  Final  AFROC  approval  joint  integ  preC.NumberOut  False= 

Final  AFROC  approval  joint  integ  preC.NumberOut  False  +  1:NEXT(461$); 

461$  ASSIGN:  Final  AFROC  resolution  joint  integ  preC.Numberln= 

Final  AFROC  resolution  joint  integ  preC.Numberln  +  1: 

Final  AFROC  resolution  joint  integ  preC.WIP=Final  AFROC  resolution  joint  integ 

preC.WIP+1; 

4559$  DELAY:  Triangular(42,48,60)„VA; 

4606$  ASSIGN:  Final  AFROC  resolution  joint  integ  preC.NumberOut= 

Final  AFROC  resolution  joint  integ  preC.NumberOut  +  1: 

Final  AFROC  resolution  joint  integ  preC.WIP=Final  AFROC  resolution  joint  integ 

preC.WIP-1 

:NEXT(4082$); 
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456$  BRANCH,  1: 

lf,AFROC  Count  PreC==l, 4609$, Yes: 

Else, 4610$, Yes; 

4609$  ASSIGN:  Check  for  previous  path  joint  integ  preC.NumberOut  True= 

Check  for  previous  path  joint  integ  preC.NumberOut  True  +  1:NEXT(462$); 

4610$  ASSIGN:  Check  for  previous  path  joint  integ  preC.NumberOut  False= 

Check  for  previous  path  joint  integ  preC.NumberOut  False  +  1:NEXT(455$); 

462$  ASSIGN:  Kill  time  at  AFROC  joint  integ  PreC=TNOW: 

TFIN=TNOW:NEXT(465$); 

465$  TALLY:  Record  25, INT(SimTime),l:NEXT(454$); 


454$  ASSIGN:  Death  at  AFROC  joint  integ  preC.NumberOut=Death  at  AFROC  joint  integ 

preC.NumberOut  +  1; 

4611$  DISPOSE:  Yes; 


455$  ASSIGN:  AFROC  Count  PreC=l:NEXT(453$); 

453$  BRANCH,  1: 

With, (99)/100, 4612$, Yes: 

Else, 4613$, Yes; 

4612$  ASSIGN:  Dead  activity  joint  integ  preC.NumberOut  True=Dead  activity  joint  integ 

preC.NumberOut  True  +  1 

:NEXT(462$); 


4613$  ASSIGN:  Dead  activity  joint  integ  preC.NumberOut  False=Dead  activity  joint  integ 

preC.NumberOut  False  +  1 

:NEXT(442$); 


451$ 


4615$ 

4662$ 


ASSIGN: 

Hold 

Hold 

Hold 

DELAY: 

ASSIGN: 

Hold 

Hold 

Hold 


Hold  for  a  year  later  in  process  2nd  time  joint  integ  preC.Numberln= 
for  a  year  later  in  process  2nd  time  joint  integ  preC.Numberln  +  1: 
for  a  year  later  in  process  2nd  time  joint  integ  preC.WIP= 
for  a  year  later  in  process  2nd  time  joint  integ  preC.WIP+1; 

Triangular(270,300,365)„NVA; 

Hold  for  a  year  later  in  process  2nd  time  joint  integ  preC.NumberOut= 
for  a  year  later  in  process  2nd  time  joint  integ  preC.NumberOut  +  1: 
for  a  year  later  in  process  2nd  time  joint  integ  preC.WIP= 
for  a  year  later  in  process  2nd  time  joint  integ  preC.WIP-l:NEXT(448$); 


450$  ASSIGN:  Hold  for  a  year  later  in  process  joint  integ  preC.Numberln= 
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4666$ 

4713$ 


Hold 

Hold 

Hold 

DELAY: 

ASSIGN: 

Hold 

Hold 

Hold 


for  a  year  later  in  process  joint  integ  preC.Numberln  +  1: 
for  a  year  later  in  process  joint  integ  preC.WIP= 
for  a  year  later  in  process  joint  integ  preC.WIP+1; 

Triangular(270,300,365)„NVA; 

Hold  for  a  year  later  in  process  joint  integ  preC.NumberOut= 
for  a  year  later  in  process  joint  integ  preC.NumberOut  +  1: 
for  a  year  later  in  process  joint  integ  preC.WIP= 
for  a  year  later  in  process  joint  integ  preC.WIP-l:NEXT(444$); 


4082$  ASSIGN:  Joint  Integration  PreC.NumberOut=Joint  Integration  PreC.NumberOut  +  1: 

Joint  Integration  PreC.WIP=Joint  Integration  PreC.WIP-l:NEXT(437$); 


;  Model  statements  for  module:  BasicProcess. Decide  152  (Check  Condition  PreC) 

/ 

401$  BRANCH,  1: 

If,  RequirementPathTrack>= 1,4716$, Yes: 

Else, 4717$, Yes; 

4716$  ASSIGN:  Check  Condition  PreC.NumberOut  True=Check  Condition  PreC.NumberOut  True 

+  1:NEXT(669$); 

4717$  ASSIGN:  Check  Condition  PreC.NumberOut  False=Check  Condition  PreC.NumberOut  False 

+  1:NEXT(400$); 


;  Model  statements  for  module:  BasicProcess. Record  13  (Record  13) 
/ 

669$  TALLY:  Record  13,INT(SimTime),l:NEXT(390$); 


;  Model  statements  for  module:  BasicProcess. Assign  79  (end  simulation  PreC) 
/ 

390$  ASSIGN:  Kill  at  Begin  of  requirements  swimlane  PreC=TNOW: 

TFIN=TNOW:NEXT(385$); 
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;  Model  statements  for  module:  BasicProcess. Dispose  34  (End  prior  to  start  of  Requirements 
swimlane  PreC) 

/ 

385$  ASSIGN:  End  prior  to  start  of  Requirements  swimlane  PreC.NumberOut= 

End  prior  to  start  of  Requirements  swimlane  PreC.NumberOut  +  1; 

4718$  DISPOSE:  No; 


;  Model  statements  for  module:  BasicProcess. Assign  81  (Add  counter  through  feedback  path  PreC) 
/ 

400$  ASSIGN:  RequirementPathTrackPreC=RequirementPathTrackPreC  +  1:NEXT(399$); 


;  Model  statements  for  module:  BasicProcess. Decide  151  (Decision  to  Repursue  PreC) 

/ 

399$  BRANCH,  1: 

With, (85)/100, 4719$, Yes: 

Else, 4720$, Yes; 

4719$  ASSIGN:  Decision  to  Repursue  PreC.NumberOut  True=Decision  to  Repursue 

PreC.NumberOut  True  +  1:NEXT(402$); 

4720$  ASSIGN:  Decision  to  Repursue  PreC.NumberOut  False=Decision  to  Repursue 

PreC.NumberOut  False  +  1:NEXT(668$); 


;  Model  statements  for  module:  BasicProcess. Process  183  (Update  Briefing  Materials  PreC) 

/ 

402$  ASSIGN:  Update  Briefing  Materials  PreC.Numberln=Update  Briefing  Materials 

PreC.Numberln  +  1: 

Update  Briefing  Materials  PreC.WIP=Update  Briefing  Materials  PreC.WIP+1; 

4722$  DELAY:  Triangular(10,35,40)„VA; 

4769$  ASSIGN:  Update  Briefing  Materials  PreC.NumberOut=Update  Briefing  Materials 

PreC.NumberOut  +  1: 

Update  Briefing  Materials  PreC.WIP=Update  Briefing  Materials  PreC.WIP-l:NEXT(394$); 
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Model  statements  for  module:  BasicProcess. Record  12  (Record  12) 


668$  TALLY:  Record  12,INT(SimTime),l:NEXT(390$); 


;  Model  statements  for  module:  BasicProcess. Decide  147  (Check  on  conditions  PreC) 

/ 

389$  BRANCH,  1: 

lf,PreCpursuerequirements==l,4772$,Yes: 

Else, 4773$, Yes; 

4772$  ASSIGN:  Check  on  conditions  PreC.NumberOut  True=Check  on  conditions 

PreC.NumberOut  True  +  1:NEXT(667$); 

4773$  ASSIGN:  Check  on  conditions  PreC.NumberOut  False=Check  on  conditions 

PreC.NumberOut  False  +  1:NEXT(391$); 


;  Model  statements  for  module:  BasicProcess. Record  11  (Record  11) 
/ 

667$  TALLY:  Record  ll,INT(SimTime),l:NEXT(390$); 


;  Model  statements  for  module:  BasicProcess. Assign  80  (Set  check  on  decision  variable  PreC) 
/ 

391$  ASSIGN:  PreCpursuerequirements=l:NEXT(392$); 


;  Model  statements  for  module:  BasicProcess. Process  179  (Wait  for  more  favorable  conditions  PreC) 
/ 

392$  ASSIGN:  Wait  for  more  favorable  conditions  PreC. Numberln= 
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Wait  for  more  favorable  conditions  PreC.Numberln  +  1: 

Wait  for  more  favorable  conditions  PreC.WIP=Wait  for  more  favorable  conditions 

PreC.WIP+1; 

4775$  DELAY:  Triangular(100,115,150)„VA; 

4822$  ASSIGN:  Wait  for  more  favorable  conditions  PreC.NumberOut= 

Wait  for  more  favorable  conditions  PreC.NumberOut  +  1: 

Wait  for  more  favorable  conditions  PreC.WIP=Wait  for  more  favorable  conditions 

PreC.WIP-1 

:NEXT(388$); 


;  Model  statements  for  module:  BasicProcess. Decide  207  (Timing  of  funds  OK?) 

/ 

574$  BRANCH,  1: 

With, (55)/100, 4825$, Yes: 

Else, 4826$, Yes; 

4825$  ASSIGN:  Timing  of  funds  OK?.NumberOut  True=Timing  of  funds  OK?.NumberOut  True  + 

1:NEXT(501$); 

4826$  ASSIGN:  Timing  of  funds  OK?.NumberOut  False=Timing  of  funds  OK?.NumberOut  False  + 

1:NEXT(575$); 


;  Model  statements  for  module:  BasicProcess. Process  229  (RFP  Release  and  Source  Selection  PreC) 
/ 

501$  ASSIGN:  RFP  Release  and  Source  Selection  PreC.Numberln=RFP  Release  and  Source 

Selection  PreC.Numberln  +  1: 

RFP  Release  and  Source  Selection  PreC.WIP=RFP  Release  and  Source  Selection 

PreC.WIP+1; 

4828$  DELAY:  Triangular(90,160,180)„VA; 

4875$  ASSIGN:  RFP  Release  and  Source  Selection  PreC.NumberOut=RFP  Release  and  Source 

Selection  PreC.NumberOut  +  1: 

RFP  Release  and  Source  Selection  PreC.WIP=RFP  Release  and  Source  Selection 
PreC.WIP-l:NEXT(502$); 
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;  Model  statements  for  module:  BasicProcess. Decide  184  (Protest  award  PreC) 

/ 

502$  BRANCH,  1: 

With, (20)/100, 4878$, Yes: 

Else, 4879$, Yes; 

4878$  ASSIGN:  Protest  award  PreC.NumberOut  True=Protest  award  PreC. NumberOut  True  + 

1:NEXT(504$); 

4879$  ASSIGN:  Protest  award  PreC.NumberOut  False=Protest  award  PreC.NumberOut  False  + 

1:NEXT(503$); 


;  Model  statements  for  module:  BasicProcess. Process  231  (Delay  for  Protest  review  PreC) 

/ 

504$  ASSIGN:  Delay  for  Protest  review  PreC.Numberln=Delay  for  Protest  review  PreC.Numberln 

+  1: 

Delay  for  Protest  review  PreC.WIP=Delay  for  Protest  review  PreC.WIP+1; 

4881$  DELAY:  Triangular(30,50,60)„VA; 

4928$  ASSIGN:  Delay  for  Protest  review  PreC.NumberOut=Delay  for  Protest  review 

PreC.NumberOut  +  1: 

Delay  for  Protest  review  PreC.WIP=Delay  for  Protest  review  PreC.WIP-l:NEXT(505$); 


;  Model  statements  for  module:  BasicProcess. Decide  185  (Protest  upheld  PreC) 

/ 

505$  BRANCH,  1: 

With, (40)/100, 4931$, Yes: 

Else, 4932$, Yes; 

4931$  ASSIGN:  Protest  upheld  PreC.NumberOut  True=Protest  upheld  PreC.NumberOut  True  + 

1:NEXT(501$); 

4932$  ASSIGN:  Protest  upheld  PreC.NumberOut  False=Protest  upheld  PreC.NumberOut  False  + 

1:NEXT(503$); 
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;  Model  statements  for  module:  BasicProcess. Process  230  (Scope  and  Award  System  Design  and 
Development  Contracts) 


503$ 


4934$ 

4981$ 


ASSIGN: 

Scope 

Scope 

Scope 

DELAY: 

ASSIGN: 

Scope 

Scope 

Scope 


Scope  and  Award  System  Design  and  Development  Contracts. Numberln= 
and  Award  System  Design  and  Development  Contracts. Numberln  +  1: 
and  Award  System  Design  and  Development  Contracts. WIP= 
and  Award  System  Design  and  Development  Contracts. WIP+1; 

T  riangular(30,100,120)„VA; 

Scope  and  Award  System  Design  and  Development  Contracts. NumberOut= 
and  Award  System  Design  and  Development  Contracts. NumberOut  +  1: 
and  Award  System  Design  and  Development  Contracts. WIP= 
and  Award  System  Design  and  Development  Contracts. WIP-1:NEXT(509$); 


;  Model  statements  for  module:  BasicProcess. Decide  186  (Path  depends  upon  ACAT  level  PreC) 
/ 

509$  BRANCH,  1: 

If, ACAT  Level==l,506$,Yes: 

If, ACAT  Level==2,507$,Yes: 

Else, 508$, Yes; 


;  Model  statements  for  module:  BasicProcess. Assign  93  (ACAT  III  Contract  Length  PreC) 
/ 

508$  ASSIGN:  SDD  contract  cost=l: 

SDD  Contract  Start=TNOW: 

SDD  original  contract  length=TRIA(365,  480,  2190):NEXT(567$); 


;  Model  statements  for  module:  BasicProcess. Assign  106  (Determine  contract  end  date  PreC) 

/ 

567$  ASSIGN:  SDD  contract  length=SDD  original  contract  length: 

SDD  Contract  End  Date=SDD  Contract  Start  +  SDD  original  contract  length:NEXT(510$); 
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;  Model  statements  for  module:  BasicProcess. Separate  22  (Split  flow  PreC) 

/ 

510$  DUPLICATE,  100-0: 

1,4988$,0:NEXT(4987$); 

4987$  ASSIGN:  Split  flow  PreC.NumberOut  Orig=Split  flow  PreC.NumberOut  Orig  + 

1:NEXT(564$); 

4988$  ASSIGN:  Split  flow  PreC.NumberOut  Dup=Split  flow  PreC.NumberOut  Dup  + 

1:NEXT(530$); 


;  Model  statements  for  module:  AdvancedProcess.Hold  15  (Wait  for  signal  for  Costing  and  Acquisition 
Planning  activities  PreC) 

/ 

564$  QUEUE,  Wait  for  signal  for  Costing  and  Acquisition  Planning  activities  PreC. Queue; 

SCAN:  Acq  Plan  PreC==l:NEXT(563$); 


;  Model  statements  for  module:  BasicProcess. Separate  27  (Split  into  Acq  Planning  and  Costing 
Activities  PreC) 

/ 

563$  DUPLICATE,  100-0: 

1,4991$,0:NEXT(4990$); 

4990$  ASSIGN:  Split  into  Acq  Planning  and  Costing  Activities  PreC.NumberOut  Orig= 

Split  into  Acq  Planning  and  Costing  Activities  PreC.NumberOut  Orig  +  1:NEXT(542$); 

4991$  ASSIGN:  Split  into  Acq  Planning  and  Costing  Activities  PreC.NumberOut  Dup= 

Split  into  Acq  Planning  and  Costing  Activities  PreC.NumberOut  Dup  +  1:NEXT(526$); 


;  Model  statements  for  module:  BasicProcess. Separate  24  (Split  into  costing  activities  PreC) 
/ 

542$  DUPLICATE,  100-0: 

1,4994$,0:NEXT(4993$); 
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4993$  ASSIGN:  Split  into  costing  activities  PreC.NumberOut  Orig= 

Split  into  costing  activities  PreC.NumberOut  Orig  +  1:NEXT(543$); 

4994$  ASSIGN:  Split  into  costing  activities  PreC.NumberOut  Dup= 

Split  into  costing  activities  PreC.NumberOut  Dup  +  1:NEXT(544$); 


;  Model  statements  for  module:  BasicProcess. Separate  25  (Second  split  into  costing  activities  PreC) 
/ 

543$  DUPLICATE,  100-0: 

1,4997$,0:NEXT(4996$); 

4996$  ASSIGN:  Second  split  into  costing  activities  PreC.NumberOut  Orig= 

Second  split  into  costing  activities  PreC.NumberOut  Orig  +  1:NEXT(545$); 

4997$  ASSIGN:  Second  split  into  costing  activities  PreC.NumberOut  Dup= 

Second  split  into  costing  activities  PreC.NumberOut  Dup  +  1:NEXT(546$); 


;  Model  statements  for  module:  BasicProcess. Process  247  (Contractor  cost  estimate  PreC) 

/ 

545$  ASSIGN:  Contractor  cost  estimate  PreC. Numberln=Contractor  cost  estimate 

PreC.Numberln  +  1: 

Contractor  cost  estimate  PreC.WIP=Contractor  cost  estimate  PreC.WIP+1; 

4999$  DELAY:  Triangular(45,50,90)„VA; 

5046$  ASSIGN:  Contractor  cost  estimate  PreC. NumberOut=Contractor  cost  estimate 

PreC.NumberOut  +  1: 

Contractor  cost  estimate  PreC.WIP=Contractor  cost  estimate  PreC.WIP-l:NEXT(547$); 


;  Model  statements  for  module:  BasicProcess. Batch  18  (for  Affordability  Assessment  PreC) 
/ 

547$  QUEUE,  for  Affordability  Assessment  PreC. Queue; 

5049$  GROUP,  , Permanent^, Last:NEXT(5050$); 
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5050$  ASSIGN:  for  Affordability  Assessment  PreC.NumberOut=for  Affordability  Assessment 

PreC.NumberOut  +  1 

:NEXT(548$); 


;  Model  statements  for  module:  BasicProcess. Process  249  (Affordability  Assessment  PreC) 

/ 

548$  ASSIGN:  Affordability  Assessment  PreC. Numberln=Affordability  Assessment 

PreC.Numberln  +  1: 

Affordability  Assessment  PreC.WIP=Affordability  Assessment  PreC.WIP+1; 

5052$  DELAY:  Triangular(120,160,180)„VA; 

5099$  ASSIGN:  Affordability  Assessment  PreC. NumberOut=Affordability  Assessment 

PreC.NumberOut  +  1: 

Affordability  Assessment  PreC.WIP=Affordability  Assessment  PreC.WIP-l:NEXT(549$); 


;  Model  statements  for  module:  BasicProcess. Separate  26  (for  funding  check  PreC) 

/ 

549$  DUPLICATE,  100-0: 

1,5104$,0:NEXT(5103$); 

5103$  ASSIGN:  for  funding  check  PreC.NumberOut  Orig=for  funding  check  PreC.NumberOut 

Orig  +  1:NEXT(485$); 

5104$  ASSIGN:  for  funding  check  PreC.NumberOut  Dup=for  funding  check  PreC.NumberOut 

Dup  +  1:NEXT(541$); 


;  Model  statements  for  module:  BasicProcess. Decide  179  (Fully  funded  to  80%  ICE  in  FYDP?  PreC) 
/ 

485$  BRANCH,  1: 

With, (90)/100, 5105$, Yes: 

Else, 5106$, Yes; 

5105$  ASSIGN:  Fully  funded  to  80%  ICE  in  FYDP?  PreC.NumberOut  True= 

Fully  funded  to  80%  ICE  in  FYDP?  PreC.NumberOut  True  +  1:NEXT(551$); 
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5106$  ASSIGN:  Fully  funded  to  80%  ICE  in  FYDP?  PreC.NumberOut  False= 

Fully  funded  to  80%  ICE  in  FYDP?  PreC.NumberOut  False  +  1:NEXT(488$); 


;  Model  statements  for  module:  AdvancedProcess.Flold  12  (KPPs  arrive  from  Requirements  PreC) 
/ 

551$  QUEUE,  KPPs  arrive  from  Requirements  PreC. Queue; 

SCAN:  KPPs  Ready  PreC==l:NEXT(550$); 


;  Model  statements  for  module:  BasicProcess. Process  250  (Set  Acquisition  Program  Baseline  PreC) 

/ 

550$  ASSIGN:  Set  Acquisition  Program  Baseline  PreC.Numberln=Set  Acquisition  Program 

Baseline  PreC.Numberln  +  1: 

Set  Acquisition  Program  Baseline  PreC.WIP=Set  Acquisition  Program  Baseline 

PreC.WIP+1; 

5108$  DELAY:  Triangular(10,25,30)„VA; 

5155$  ASSIGN:  Set  Acquisition  Program  Baseline  PreC. NumberOut=Set  Acquisition  Program 

Baseline  PreC.NumberOut  +  1: 

Set  Acquisition  Program  Baseline  PreC.WIP=Set  Acquisition  Program  Baseline  PreC.WIP- 

1:NEXT(631$); 


;  Model  statements  for  module:  BasicProcess. Assign  128  (Notify  PreC  Baseline) 
/ 

631$  ASSIGN:  PreC  Baseline=l:NEXT(494$); 


;  Model  statements  for  module:  BasicProcess. Batch  16  (Complete  predecessor  activities  preC) 
/ 

494$  QUEUE,  Complete  predecessor  activities  preC. Queue; 

5158$  GROUP,  , Permanent^, Last:NEXT(5159$); 
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5159$  ASSIGN:  Complete  predecessor  activities  preC.NumberOut=Complete  predecessor 

activities  preC.NumberOut  +  1 
:NEXT(632$); 


;  Model  statements  for  module:  BasicProcess. Process  271  (Acquisition  Panels  preparation  PreC) 

/ 

632$  ASSIGN:  Acquisition  Panels  preparation  PreC.Numberln=Acquisition  Panels  preparation 

PreC.Numberln  +  1: 

Acquisition  Panels  preparation  PreC.WIP=Acquisition  Panels  preparation  PreC.WIP+1; 
5161$  DELAY:  ACAT  level==l*TRIA(40,56,60)+ACAT  level==2*TRIA(15,25,30)  +  ACAT 

level==3*TRIA(15,25,30)„VA; 

5208$  ASSIGN:  Acquisition  Panels  preparation  PreC.NumberOut=Acquisition  Panels  preparation 

PreC.NumberOut  +  1: 

Acquisition  Panels  preparation  PreC.WIP=Acquisition  Panels  preparation  PreC.WIP- 

1:NEXT(633$); 


;  Model  statements  for  module:  BasicProcess. Batch  20  (Wait  for  RFP  Coord  Process  to  end) 

/ 

633$  QUEUE,  Wait  for  RFP  Coord  Process  to  end. Queue; 

5211$  GROUP,  , Permanent^, Last:NEXT(5212$); 

5212$  ASSIGN:  Wait  for  RFP  Coord  Process  to  end.NumberOut=Wait  for  RFP  Coord  Process  to 

end.NumberOut  +  1 

:NEXT(495$); 


;  Model  statements  for  module:  BasicProcess. Process  228  (Acquisition  Panels  PreC) 

/ 

495$  ASSIGN:  Acquisition  Panels  PreC.Numberln=Acquisition  Panels  PreC.Numberln  +  1: 

Acquisition  Panels  PreC.WIP=Acquisition  Panels  PreC.WIP+1; 

5214$  DELAY:  Triangular(15,30,35)„VA; 

5261$  ASSIGN:  Acquisition  Panels  PreC.NumberOut=Acquisition  Panels  PreC.NumberOut  +  1: 

Acquisition  Panels  PreC.WIP=Acquisition  Panels  PreC.WIP-l:NEXT(553$); 
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Model  statements  for  module:  BasicProcess. Decide  180  (ACAT  level  preC) 


488$  BRANCH,  1: 

If, ACAT  Level==l, 5264$, Yes: 

Else, 5265$, Yes; 

5264$  ASSIGN:  ACAT  level  preC.NumberOut  True=ACAT  level  preC.NumberOut  True  + 

1:NEXT(486$); 

5265$  ASSIGN:  ACAT  level  preC.NumberOut  False=ACAT  level  preC.NumberOut  False  + 

1:NEXT(487$); 


;  Model  statements  for  module:  BasicProcess. Process  221  (ACAT  I  time  delay  PreC) 

/ 

486$  ASSIGN:  ACAT  I  time  delay  PreC.Numberln=ACAT  I  time  delay  PreC.Numberln  +  1: 

ACAT  I  time  delay  PreC.WIP=ACAT  I  time  delay  PreC.WIP+1; 

5267$  DELAY:  Triangular(30,120,180)„VA; 

5314$  ASSIGN:  ACAT  I  time  delay  PreC.NumberOut=ACAT  I  time  delay  PreC.NumberOut  +  1: 

ACAT  I  time  delay  PreC.WIP=ACAT  I  time  delay  PreC.WIP-l:NEXT(551$); 


;  Model  statements  for  module:  BasicProcess. Process  222  (ACAT  II  or  ACAT  III  time  delay  PreC) 

/ 

487$  ASSIGN:  ACAT  II  or  ACAT  III  time  delay  PreC.Numberln=ACAT  II  or  ACAT  III  time  delay 

PreC.Numberln  +  1: 

ACAT  II  or  ACAT  III  time  delay  PreC.WIP=ACAT  II  or  ACAT  III  time  delay  PreC.WIP+1; 
5318$  DELAY:  Triangular(90,225,270)„VA; 

5365$  ASSIGN:  ACAT  II  or  ACAT  III  time  delay  PreC.NumberOut=ACAT  II  or  ACAT  III  time  delay 

PreC.NumberOut  +  1: 

ACAT  II  or  ACAT  III  time  delay  PreC.WIP=ACAT  II  or  ACAT  III  time  delay  PreC.WIP- 

1:NEXT(551$); 
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;  Model  statements  for  module:  BasicProcess. Batch  17  (Bring  the  processes  together  PreC) 

/ 

541$  QUEUE,  Bring  the  processes  together  PreC. Queue; 

5368$  GROUP,  , Permanent^, Last:NEXT(5369$); 

5369$  ASSIGN:  Bring  the  processes  together  PreC.NumberOut=Bring  the  processes  together 

PreC.NumberOut  +  1 

:NEXT(633$); 


;  Model  statements  for  module:  BasicProcess. Process  248  (Independent  Cost  Estimate  PreC) 

/ 

546$  ASSIGN:  Independent  Cost  Estimate  PreC.Numberln=lndependent  Cost  Estimate 

PreC.Numberln  +  1: 

Independent  Cost  Estimate  PreC.WIP=lndependent  Cost  Estimate  PreC.WIP+1; 
5371$  DELAY:  Triangular(30,35,60)„VA; 

5418$  ASSIGN:  Independent  Cost  Estimate  PreC.NumberOut=lndependent  Cost  Estimate 

PreC.NumberOut  +  1: 

Independent  Cost  Estimate  PreC.WIP=lndependent  Cost  Estimate  PreC.WIP- 

1:NEXT(547$); 


;  Model  statements  for  module:  BasicProcess. Process  246  (Program  Office  Cost  Estimate  PreC) 

/ 

544$  ASSIGN:  Program  Office  Cost  Estimate  PreC.Numberln=Program  Office  Cost  Estimate 

PreC.Numberln  +  1: 

Program  Office  Cost  Estimate  PreC.WIP=Program  Office  Cost  Estimate  PreC.WIP+1; 
5422$  DELAY:  Triangular(60,65,90)„VA; 

5469$  ASSIGN:  Program  Office  Cost  Estimate  PreC.NumberOut=Program  Office  Cost  Estimate 

PreC.NumberOut  +  1: 

Program  Office  Cost  Estimate  PreC.WIP=Program  Office  Cost  Estimate  PreC.WIP- 

1:NEXT(547$); 


Model  statements  for  module:  BasicProcess. Process  234  (Acquisition  Planning  Activities  PreC) 
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526$  ASSIGN:  Acquisition  Planning  Activities  PreC.Numberln=Acquisition  Planning  Activities 

PreC.Numberln  +  1: 

Acquisition  Planning  Activities  PreC.WIP=Acquisition  Planning  Activities 
PreC.WIP+l:NEXT(527$); 

527$  BRANCH,  1: 

lf,ACAT  Level==l, 5523$, Yes: 

Else, 5524$, Yes; 

5523$  ASSIGN:  Acq  planning  activities  depend  upon  ACAT  level  preC.NumberOut  True= 

Acq  planning  activities  depend  upon  ACAT  level  preC.NumberOut  True  +  1:NEXT(528$); 

5524$  ASSIGN:  Acq  planning  activities  depend  upon  ACAT  level  preC.NumberOut  False= 

Acq  planning  activities  depend  upon  ACAT  level  preC.NumberOut  False  +  1:NEXT(529$); 

528$  ASSIGN:  ACAT  I  Acquisition  Planning  PreC.Numberln=ACAT  I  Acquisition  Planning 

PreC.Numberln  +  1: 

ACAT  I  Acquisition  Planning  PreC.WIP=ACAT  I  Acquisition  Planning  PreC.WIP+1; 

5526$  DELAY:  Triangular(120,240,250)„VA; 

5573$  ASSIGN:  ACAT  I  Acquisition  Planning  PreC.NumberOut=ACAT  I  Acquisition  Planning 

PreC.NumberOut  +  1: 

ACAT  I  Acquisition  Planning  PreC.WIP=ACAT  I  Acquisition  Planning  PreC.WIP- 

1:NEXT(5520$); 

529$  ASSIGN:  ACAT  II  Or  III  Acquisition  Planning  PreC.Numberln= 

ACAT  II  Or  III  Acquisition  Planning  PreC.Numberln  +  1: 

ACAT  II  Or  III  Acquisition  Planning  PreC.WIP=ACAT  II  Or  III  Acquisition  Planning 

PreC.WIP+1; 

5577$  DELAY:  Triangular(120,185,250)„VA; 

5624$  ASSIGN:  ACAT  II  Or  III  Acquisition  Planning  PreC.NumberOut= 

ACAT  II  Or  III  Acquisition  Planning  PreC.NumberOut  +  1: 

ACAT  II  Or  III  Acquisition  Planning  PreC.WIP=ACAT  II  Or  III  Acquisition  Planning 

PreC.WIP-1 

:NEXT(5520$); 

5520$  ASSIGN:  Acquisition  Planning  Activities  PreC.NumberOut=Acquisition  Planning  Activities 

PreC.NumberOut  +  1: 

Acquisition  Planning  Activities  PreC.WIP=Acquisition  Planning  Activities  PreC.WIP- 

1:NEXT(489$); 
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Model  statements  for  module:  BasicProcess. Batch  15  (Processes  come  together  PreC) 


489$  QUEUE,  Processes  come  together  PreC. Queue; 
5627$  GROUP,  , Permanent^, Last:NEXT(5628$); 


5628$  ASSIGN:  Processes  come  together  PreC.NumberOut=Processes  come  together 

PreC.NumberOut  +  1:NEXT(490$); 


;  Model  statements  for  module:  BasicProcess. Process  223  (Draft  RFP  Preparation  preC) 

/ 

490$  ASSIGN:  Draft  RFP  Preparation  preC.Numberln=Draft  RFP  Preparation  preC.Numberln  +  1: 

Draft  RFP  Preparation  preC.WIP=Draft  RFP  Preparation  preC.WIP+1; 

5630$  DELAY:  Triangular(10,17,20)„VA; 

5677$  ASSIGN:  Draft  RFP  Preparation  preC.NumberOut=Draft  RFP  Preparation  preC.NumberOut 

+  1: 

Draft  RFP  Preparation  preC.WIP=Draft  RFP  Preparation  preC.WIP-l:NEXT(491$); 


;  Model  statements  for  module:  BasicProcess. Separate  21  (Separate  activities  once  preC) 

/ 

491$  DUPLICATE,  100-0: 

1,5682$,0:NEXT(5681$); 

5681$  ASSIGN:  Separate  activities  once  preC.NumberOut  Orig=Separate  activities  once 

preC.NumberOut  Orig  +  1 

:NEXT(492$); 

5682$  ASSIGN:  Separate  activities  once  preC.NumberOut  Dup=Separate  activities  once 

preC.NumberOut  Dup  +  1 

:NEXT(629$); 


Model  statements  for  module:  BasicProcess. Process  224  (RFP  Coordination  Process  PreC) 
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492$  ASSIGN:  RFP  Coordination  Process  PreC.Numberln=RFP  Coordination  Process 

PreC.Numberln  +  1: 

RFP  Coordination  Process  PreC.WIP=RFP  Coordination  Process  PreC.WIP+1; 

5684$  DELAY:  Triangular(25,45,50)„VA; 

5731$  ASSIGN:  RFP  Coordination  Process  PreC.NumberOut=RFP  Coordination  Process 

PreC.NumberOut  +  1: 

RFP  Coordination  Process  PreC.WIP=RFP  Coordination  Process  PreC.WIP-l:NEXT(541$); 


;  Model  statements  for  module:  AdvancedProcess.Hold  20  (Wait  for  Baseline  set  PreC) 
/ 

629$  QUEUE,  Wait  for  Baseline  set  PreC. Queue; 

SCAN:  PreC  Baseline==l:NEXT(493$); 


;  Model  statements  for  module:  BasicProcess. Process  225  (Source  selection  plans  preC) 

/ 

493$  ASSIGN:  Source  selection  plans  preC.Numberln=Source  selection  plans  preC.Numberln  + 

1: 

Source  selection  plans  preC.WIP=Source  selection  plans  preC.WIP+1; 

5735$  DELAY:  Triangular(30,60,65)„VA; 

5782$  ASSIGN:  Source  selection  plans  preC.NumberOut=Source  selection  plans 

preC.NumberOut  +  1: 

Source  selection  plans  preC.WIP=Source  selection  plans  preC.WIP-l:NEXT(494$); 


;  Model  statements  for  module:  BasicProcess. Process  237  (Contract  Startup  PreC) 

/ 

530$  ASSIGN:  Contract  Startup  PreC.Numberln=Contract  Startup  PreC.Numberln  +  1: 

Contract  Startup  PreC.WIP=Contract  Startup  PreC.WIP+1; 

5786$  DELAY:  Triangular(30,42,45)„VA; 

5833$  ASSIGN:  Contract  Startup  PreC.NumberOut=Contract  Startup  PreC.NumberOut  +  1: 

Contract  Startup  PreC.WIP=Contract  Startup  PreC.WIP-l:NEXT(566$); 
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;  Model  statements  for  module:  BasicProcess. Assign  105  (Set  Contract  Start  variable  PreC) 
/ 

566$  ASSIGN:  Contract  Start  PreC=l:NEXT(557$); 


;  Model  statements  for  module:  AdvancedProcess. Hold  13  (Wait  for  PDR) 
/ 

557$  QUEUE,  Wait  for  PDR.Queue; 

SCAN:  PDR==1:NEXT(581$); 


;  Model  statements  for  module:  BasicProcess. Decide  211  (PDR  success??) 

/ 

581$  BRANCH,  1: 

With, (25)/100, 5836$, Yes: 

Else, 5837$, Yes; 

5836$  ASSIGN:  PDR  success??. NumberOut  True=PDR  success??. NumberOut  True  + 

1:NEXT(592$); 

5837$  ASSIGN:  PDR  success??. NumberOut  False=PDR  success??. NumberOut  False  + 

1:NEXT(648$); 


;  Model  statements  for  module:  AdvancedProcess. Hold  19  (Wait  for  CDR) 
/ 

592$  QUEUE,  Wait  for  CDR. Queue; 

SCAN:  CDR==1:NEXT(594$); 


;  Model  statements  for  module:  BasicProcess. Decide  215  (CDR  success??) 
/ 

594$  BRANCH,  1: 

With, (70)/100, 5838$, Yes: 
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Else, 5839$, Yes; 

5838$  ASSIGN:  CDR  success??. NumberOut  True=CDR  success??. NumberOut  True  + 

1:NEXT(602$); 

5839$  ASSIGN:  CDR  success??. NumberOut  False=CDR  success??. NumberOut  False  + 

1:NEXT(650$); 


;  Model  statements  for  module:  BasicProcess. Process  260  (Preparation  for  Acqiusition  Panels  before 
DRR) 

/ 

602$  ASSIGN:  Preparation  for  Acqiusition  Panels  before  DRR. Numberln= 

Preparation  for  Acqiusition  Panels  before  DRR.Numberln  +  1: 

Preparation  for  Acqiusition  Panels  before  DRR.WIP= 

Preparation  for  Acqiusition  Panels  before  DRR.WIP+1; 

5841$  DELAY:  Triangular(25,50,60)„VA; 

5888$  ASSIGN:  Preparation  for  Acqiusition  Panels  before  DRR.NumberOut= 

Preparation  for  Acqiusition  Panels  before  DRR. NumberOut  +  1: 

Preparation  for  Acqiusition  Panels  before  DRR.WIP= 

Preparation  for  Acqiusition  Panels  before  DRR.WIP-1:NEXT(603$); 


Model  statements  for  module:  BasicProcess. Process  261  (Pre  DRR  Acquisition  Panels) 


603$ 

ASSIGN: 

Pre 

5892$ 

DELAY: 

5939$ 

ASSIGN: 

+  1: 

Pre 

Pre  DRR  Acquisition  Panels. Numberln=Pre  DRR  Acquisition  Panels. Numberln  +  1: 
DRR  Acquisition  Panels. WIP=Pre  DRR  Acquisition  Panels. WIP+1; 
Triangular(3,12,15)„VA; 

Pre  DRR  Acquisition  Panels. NumberOut=Pre  DRR  Acquisition  Panels. NumberOut 
DRR  Acquisition  Panels. WIP=Pre  DRR  Acquisition  Panels. WIP-1:NEXT(604$); 


;  Model  statements  for  module:  BasicProcess. Decide  219  (Design  Readiness  Review) 
/ 

604$  BRANCH,  1: 

With, (90)/100,5942$, Yes: 


434 


Else, 5943$, Yes; 

5942$  ASSIGN:  Design  Readiness  Review. NumberOut  True=Design  Readiness 

Review. NumberOut  True  +  1:NEXT(622$); 

5943$  ASSIGN:  Design  Readiness  Review. NumberOut  False=Design  Readiness 

Review. NumberOut  False  +  1:NEXT(623$); 


;  Model  statements  for  module:  BasicProcess. Assign  124  (Notify  Requirements  about  DRR  success) 
/ 

622$  ASSIGN:  DRR  Success=l:NEXT(607$); 


;  Model  statements  for  module:  BasicProcess. Process  263  (Fabrication) 

/ 

607$  ASSIGN:  Fabrication.  Numberln=Fabrication.  Numberln  +  1: 

Fabrication.WIP=Fabrication.WIP+l; 

5945$  DELAY: 

TRIA(.06*SDD  original  contract  length,  ,1*SDD  original  contract  length,  ,11*SDD  original 
contract  length),, 

VA; 

5992$  ASSIGN:  Fabrication.  NumberOut=Fabrication.  NumberOut  +  1: 

Fabrication.WIP=Fabrication.WIP-l:NEXT(609$); 


;  Model  statements  for  module:  BasicProcess. Process  264  (Assembly) 

/ 

609$  ASSIGN:  Assembly.  Numberln=Assembly.  Numberln  +  1: 

Assembly.  WIP=Assembly.WIP+l; 

5996$  DELAY: 

TRIA(.06*SDD  original  contract  length,  ,1*SDD  original  contract  length,  ,11*SDD  original 
contract  length),, 

VA; 

6043$  ASSIGN:  Assembly.  NumberOut=Assembly.  NumberOut  +  1: 

Assembly.  WIP=Assembly.WIP-l:NEXT(610$); 
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;  Model  statements  for  module:  BasicProcess. Process  265  (Integrated  Testing) 

/ 

610$  ASSIGN:  Integrated  Testing. Numberln=lntegrated  Testing. Numberln  +  1: 

Integrated  Testing. WIP=lntegrated  Testing. WIP+1; 

6047$  DELAY: 

TRIA(ACAT  Level==l*0.15*SDD  original  contract  length+ACAT  Level==2*0.07*SDD 
original  contract  length+ACAT  Level==3*0.07*SDD  original  contract  length, ACAT  Level==l*0.25*SDD 
original  contract  length+ACAT  Level==2*0.1*SDD  original  contract  length+ACAT  Level==3*0.1*SDD 
original  contract  length, ACAT  Level==l*0.26*SDD  original  contract  length+ACAT  Level==2*0.11*SDD 
original  contract  length+ACAT  Level==3*0.11*SDD  original  contract  length),, 

VA; 

6094$  ASSIGN:  Integrated  Testing. NumberOut=lntegrated  Testing. NumberOut  +  1: 

Integrated  Testing. WIP=lntegrated  Testing. WIP-1:NEXT(611$); 


;  Model  statements  for  module:  BasicProcess. Decide  220  (Test  Readiness  Review) 

/ 

611$  BRANCH,  1: 

With, (70)/100, 6097$, Yes: 

Else, 6098$, Yes; 

6097$  ASSIGN:  Test  Readiness  Review. NumberOut  True=Test  Readiness  Review. NumberOut 

True  +  1:NEXT(615$); 

6098$  ASSIGN:  Test  Readiness  Review. NumberOut  False=Test  Readiness  Review. NumberOut 

False  +  1:NEXT(624$); 


;  Model  statements  for  module:  BasicProcess. Process  267  (Developmental  system  testing  and  Live 
Fire  test  and  Operational  Assessment  testing) 

/ 

615$  ASSIGN:  Developmental  system  testing  and  Live  Fire  test  and  Operational  Assessment 

testing.  Numberln= 

Developmental  system  testing  and  Live  Fire  test  and  Operational  Assessment 
testing. Numberln  +  1: 
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Developmental  system  testing  and  Live  Fire  test  and  Operational  Assessment 

testing. WIP= 

Developmental  system  testing  and  Live  Fire  test  and  Operational  Assessment 

testing. WIP+1; 

6100$  DELAY: 

TRIA(ACAT  Level==l*0.18*SDD  original  contract  length+ACAT  Level==2*0.1*SDD 
original  contract  length+ACAT  Level==3*0.1*SDD  original  contract  length, ACAT  Level==l*0.25*SDD 
original  contract  length+ACAT  Level==2*0.15*SDD  original  contract  length+ACAT  Level==3*0.15*SDD 
original  contract  length, ACAT  Level==l*0.27*SDD  original  contract  length+ACAT  Level==2*0.17*SDD 
original  contract  length+ACAT  Level==3*0.17*SDD  original  contract  length),, 

VA; 

6147$  ASSIGN:  Developmental  system  testing  and  Live  Fire  test  and  Operational  Assessment 

testing.  NumberOut= 

Developmental  system  testing  and  Live  Fire  test  and  Operational  Assessment 
testing. NumberOut  +  1: 

Developmental  system  testing  and  Live  Fire  test  and  Operational  Assessment 

testing.  WIP= 

Developmental  system  testing  and  Live  Fire  test  and  Operational  Assessment 
testing.  WIP-1:NEXT(616$); 


;  Model  statements  for  module:  BasicProcess. Decide  221  (Make  Trades?) 

/ 

616$  BRANCH,  1: 

With, (50)/100, 6150$, Yes: 

Else, 6151$, Yes; 

6150$  ASSIGN:  Make  Trades?. NumberOut  True=Make  Trades?. NumberOut  True  + 

1:NEXT(621$); 

6151$  ASSIGN:  Make  Trades?. NumberOut  False=Make  Trades?. NumberOut  False  + 

1:NEXT(620$); 


;  Model  statements  for  module:  BasicProcess. Process  269  (Combined  Testing) 

/ 

621$  ASSIGN:  Combined  Testing. Numberln=Combined  Testing. Numberln  +  1: 

Combined  Testing. WIP=Combined  Testing. WIP+1; 

6153$  DELAY: 
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TRIA(.07*SDD  original  contract  length,  0.1*SDD  original  contract  length,  0.11*SDD 
original  contract  length),, 

VA; 

6200$  ASSIGN:  Combined  Testing. NumberOut=Combined  Testing. NumberOut  +  1: 

Combined  Testing. WIP=Combined  Testing. WIP-1:NEXT(651$); 


;  Model  statements  for  module:  BasicProcess. Assign  145  (Assign  Set  close  to  end  SDD  contract 
condition) 

/ 

651$  ASSIGN:  SDD  Contract  condition  end  is  close=l:NEXT(538$); 


;  Model  statements  for  module:  BasicProcess. Decide  204  (System  Verification  Review) 

/ 

538$  BRANCH,  1: 

With, (85)/100, 6203$, Yes: 

Else, 6204$, Yes; 

6203$  ASSIGN:  System  Verification  Review. NumberOut  True=System  Verification 

Review. NumberOut  True  +  1:NEXT(540$); 

6204$  ASSIGN:  System  Verification  Review. NumberOut  False=System  Verification 

Review. NumberOut  False  +  1 
:NEXT(626$); 


;  Model  statements  for  module:  BasicProcess. Assign  102  (Engineering  Development  model  delivery) 
/ 

540$  ASSIGN:  End  SDD  contracts 

SDD  Final  contract  length=SDD  contract  length: 

Engineering  Development  model=TNOW:NEXT(627$); 


Model  statements  for  module:  BasicProcess. Process  270  (Initial  Rate  Production  Baseline) 


438 


627$  ASSIGN:  Initial  Rate  Production  Baseline. Numberln=lnitial  Rate  Production 

Baseline.  Numberln  +  1: 

Initial  Rate  Production  Baseline. WIP=lnitial  Rate  Production  Baseline. WIP+1; 

6206$  DELAY:  Triangular(15,30,35)„VA; 

6253$  ASSIGN:  Initial  Rate  Production  Baseline. NumberOut=lnitial  Rate  Production 

Baseline. NumberOut  +  1: 

Initial  Rate  Production  Baseline. WIP=lnitial  Rate  Production  Baseline. WIP-1:NEXT(489$); 


;  Model  statements  for  module:  BasicProcess. Assign  126  (Set  SVR  rework) 
/ 

626$  ASSIGN:  SVR  rework=TRIA(30,160,180):NEXT(539$); 


;  Model  statements  for  module:  BasicProcess. Process  245  (SVR  rework  and  delay) 

/ 

539$  ASSIGN:  SVR  rework  and  delay. Numberln=SVR  rework  and  delay. Numberln  +  1: 

SVR  rework  and  delay. WIP=SVR  rework  and  delay. WIP+1; 

6257$  DELAY:  SVR  rework,, VA; 

6304$  ASSIGN:  SVR  rework  and  delay. NumberOut=SVR  rework  and  delay. NumberOut  +  1: 

SVR  rework  and  delay. WIP=SVR  rework  and  delay. WIP-1:NEXT(625$); 


;  Model  statements  for  module:  BasicProcess. Assign  125  (Set  SVR  delay  cost  and  schedule  penalties) 
/ 

625$  ASSIGN:  SDD  contract  length=SDD  contract  length  +  SVR  rework: 

SDD  Contract  End  Date=SDD  Contract  End  Date  +  SVR  Rework: 

SDD  contract  cost=SDD  contract  cost  +  (,05*SDD  contract  cost):NEXT(616$); 


;  Model  statements  for  module:  BasicProcess. Decide  222  (Check  looping  condition) 
/ 

620$  BRANCH,  1: 
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If, trade  counter==0, 6307$, Yes: 

Else, 6308$, Yes; 

6307$  ASSIGN:  Check  looping  condition. NumberOut  True=Check  looping  condition. NumberOut 

True  +  1:NEXT(617$); 

6308$  ASSIGN:  Check  looping  condition. NumberOut  False=Check  looping  condition. NumberOut 

False  +  1:NEXT(621$); 


;  Model  statements  for  module:  BasicProcess. Assign  122  (Determine  trades  delay) 
/ 

617$  ASSIGN:  Trades  Delay=TRIA(30, 60, 180):NEXT(618$); 


;  Model  statements  for  module:  BasicProcess. Process  268  (Trades  Delay  PreC) 

/ 

618$  ASSIGN:  Trades  Delay  PreC.Numberln=Trades  Delay  PreC.Numberln  +  1: 

Trades  Delay  PreC.WIP=Trades  Delay  PreC.WIP+1; 

6310$  DELAY:  Trades  Delay,, VA; 

6357$  ASSIGN:  Trades  Delay  PreC.NumberOut=Trades  Delay  PreC. NumberOut  +  1: 

Trades  Delay  PreC.WIP=Trades  Delay  PreC.WIP-l:NEXT(619$); 


;  Model  statements  for  module:  BasicProcess. Assign  123  (Determine  cost  and  schedule  penalties  for 
trades  delays) 

/ 

619$  ASSIGN:  trade  counter=l: 

SDD  contract  length=SDD  contract  length  +  Trades  Delay: 

SDD  Contract  End  Date=SDD  Contract  End  Date  +  Trades  Delay: 

SDD  contract  cost=SDD  contract  cost  +  (0.02*SDD  contract  cost):NEXT(615$); 


Model  statements  for  module:  BasicProcess. Decide  224  (Check  TRR  looping  condition) 
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624$  BRANCH,  1: 

IfJRR  loop==0, 6360$, Yes: 

Else, 6361$, Yes; 

6360$  ASSIGN:  Check  TRR  looping  condition. NumberOut  True=Check  TRR  looping 

condition.  NumberOut  True  +  1 
:NEXT(612$); 

6361$  ASSIGN:  Check  TRR  looping  condition. NumberOut  False=Check  TRR  looping 

condition. NumberOut  False  +  1 
:NEXT(615$); 


;  Model  statements  for  module:  BasicProcess. Assign  120  (Determine  TRR  delay) 
/ 

612$  ASSIGN:  TRR  Delay=TRIA(30,60,180):NEXT(613$); 


;  Model  statements  for  module:  BasicProcess. Process  266  (TRR  Delay  PreC) 

/ 

613$  ASSIGN:  TRR  Delay  PreC. Numberln=TRR  Delay  PreC. Numberln  +  1: 

TRR  Delay  PreC.WIP=TRR  Delay  PreC.WIP+1; 

6363$  DELAY:  TRR  Delay,, VA; 

6410$  ASSIGN:  TRR  Delay  PreC. NumberOut=TRR  Delay  PreC. NumberOut  +  1: 

TRR  Delay  PreC.WIP=TRR  Delay  PreC.WIP-l:NEXT(614$); 


;  Model  statements  for  module:  BasicProcess. Assign  121  (Determine  cost  and  schedule  penalties  for 
TRR  delays) 

/ 

614$  ASSIGN:  TRR  loop=l: 

SDD  contract  length=SDD  contract  length  +  TRR  Delay: 

SDD  Contract  End  Date=SDD  Contract  End  Date  +  TRR  Delay: 

SDD  contract  cost=SDD  contract  cost  +  (0.01*SDD  contract  cost):NEXT(611$); 
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;  Model  statements  for  module:  BasicProcess. Decide  223  (Check  DRR  looping  condition) 
/ 

623$  BRANCH,  1: 

If, DRR  loop==0, 6413$, Yes: 

Else, 6414$, Yes; 

6413$  ASSIGN:  Check  DRR  looping  condition. NumberOut  True=Check  DRR  looping 

condition. NumberOut  True  +  1 
:NEXT(606$); 

6414$  ASSIGN:  Check  DRR  looping  condition. NumberOut  False=Check  DRR  looping 

condition. NumberOut  False  +  1 
:NEXT(622$); 


;  Model  statements  for  module:  BasicProcess. Assign  118  (Determine  DRR  Rework) 
/ 

606$  ASSIGN:  DRR  Rework=TRIA(30,150,180):NEXT(605$); 


;  Model  statements  for  module:  BasicProcess. Process  262  (DRR  rework  and  delay) 

/ 

605$  ASSIGN:  DRR  rework  and  delay. Numberln=DRR  rework  and  delay. Numberln  +  1: 

DRR  rework  and  delay. WIP=DRR  rework  and  delay. WIP+1; 

6416$  DELAY:  DRR  Rework,, VA; 

6463$  ASSIGN:  DRR  rework  and  delay. NumberOut=DRR  rework  and  delay. NumberOut  +  1: 

DRR  rework  and  delay. WIP=DRR  rework  and  delay. WIP-1:NEXT(608$); 


;  Model  statements  for  module:  BasicProcess. Assign  119  (Assign  cost  penalty  for  DRR  rework) 
/ 

608$  ASSIGN:  DRR  loop=l: 

SDD  contract  cost=SDD  contract  cost  +(.01*SDD  contract  cost): 

SDD  contract  length=SDD  contract  length  +  DRR  Rework: 

SDD  Contract  End  Date=SDD  Contract  End  Date  +  DRR  Rework:NEXT(604$); 
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Model  statements  for  module:  BasicProcess. Assign  144  (Assign  CDR  Rework  time) 


650$  ASSIGN:  CDR  Rework  time=.15*(TNOW-SDD  contract  length  ):NEXT(595$); 


;  Model  statements  for  module:  BasicProcess. Process  257  (CDR  Rework  PreC) 

/ 

595$  ASSIGN:  CDR  Rework  PreC. Numberln=CDR  Rework  PreC. Numberln  +  1: 

CDR  Rework  PreC.WIP=CDR  Rework  PreC.WIP+1; 

6467$  DELAY:  CDR  Rework  time,, VA; 

6514$  ASSIGN:  CDR  Rework  PreC.NumberOut=CDR  Rework  PreC.NumberOut  +  1: 

CDR  Rework  PreC.WIP=CDR  Rework  PreC.WIP-l:NEXT(596$); 


;  Model  statements  for  module:  BasicProcess. Assign  115  (Assign  CDR1  Cost  and  Schedule  Penalty) 
/ 

596$  ASSIGN:  SDD  contract  length=SDD  contract  length  +  CDR  Rework  time: 

SDD  Contract  End  Date=SDD  Contract  End  Date  +  PDR  Rework  time: 

SDD  contract  cost=SDD  contract  cost  +  (,1*SDD  contract  cost):NEXT(597$); 


;  Model  statements  for  module:  BasicProcess. Decide  216  (CDR  2) 

/ 

597$  BRANCH,  1: 

With, (90)/100, 6517$, Yes: 

Else, 6518$, Yes; 

6517$  ASSIGN:  CDR  2.NumberOut  True=CDR  2.NumberOut  True  +  1:NEXT(602$); 
6518$  ASSIGN:  CDR  2.NumberOut  False=CDR  2.NumberOut  False  +  1:NEXT(598$); 
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;  Model  statements  for  module:  BasicProcess. Process  258  (CDR  delay  2  PreC) 

/ 

598$  ASSIGN:  CDR  delay  2  PreC. Numberln=CDR  delay  2  PreC. Numberln  +  1: 

CDR  delay  2  PreC.WIP=CDR  delay  2  PreC.WIP+1; 

6520$  DELAY:  ,5*CDR  Rework  time,, VA; 

6567$  ASSIGN:  CDR  delay  2  PreC.NumberOut=CDR  delay  2  PreC.NumberOut  +  1: 

CDR  delay  2  PreC.WIP=CDR  delay  2  PreC.WIP-l:NEXT(599$); 


;  Model  statements  for  module:  BasicProcess. Assign  116  (Assign  CDR2  Cost  and  Schedule  Penalty) 
/ 

599$  ASSIGN:  SDD  contract  length=SDD  contract  length  +  (0.5*CDR  Rework  time): 

SDD  Contract  End  Date=SDD  Contract  End  Date  +  (0.5*PDR  Rework  time): 

SDD  contract  cost=SDD  contract  cost  +  (,1*SDD  contract  cost):NEXT(600$); 


;  Model  statements  for  module:  BasicProcess. Decide  217  (CDR  3) 

/ 

600$  BRANCH,  1: 

With, (99)/100, 6570$, Yes: 

Else, 6571$, Yes; 

6570$  ASSIGN:  CDR  3.NumberOut  True=CDR  3.NumberOut  True  +  1:NEXT(602$); 
6571$  ASSIGN:  CDR  3.NumberOut  False=CDR  3.NumberOut  False  +  1:NEXT(640$); 


;  Model  statements  for  module:  BasicProcess. Assign  136  (Assign  Program  Kill  at  CDR) 
/ 

640$  ASSIGN:  TFIN=TNOW: 

Program  Kill  Time  at  CDR=TNOW:NEXT(673$); 


Model  statements  for  module:  BasicProcess. Record  17  (Record  17) 
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673$  TALLY: 


Record  17,INT(SimTime),l:NEXT(601$); 


;  Model  statements  for  module:  BasicProcess. Dispose  48  (Program  Kill  at  CDR) 

/ 

601$  ASSIGN:  Program  Kill  at  CDR.NumberOut=Program  Kill  at  CDR.NumberOut  +  1; 

6572$  DISPOSE:  No; 


;  Model  statements  for  module:  BasicProcess. Assign  142  (Assign  PDR1  rework  time) 
/ 

648$  ASSIGN:  PDR  rework=.15*(TNOW-SDD  Contract  Start) : N EXT(582$); 


;  Model  statements  for  module:  BasicProcess. Process  254  (PDR  Rework  PreC) 

/ 

582$  ASSIGN:  PDR  Rework  PreC. Numberln=PDR  Rework  PreC. Numberln  +  1: 

PDR  Rework  PreC.WIP=PDR  Rework  PreC.WIP+1; 

6574$  DELAY:  PDR  rework,, VA; 

6621$  ASSIGN:  PDR  Rework  PreC.NumberOut=PDR  Rework  PreC.NumberOut  +  1: 

PDR  Rework  PreC.WIP=PDR  Rework  PreC.WIP-l:NEXT(583$); 


;  Model  statements  for  module:  BasicProcess. Assign  112  (Assign  PDR1  Cost  and  Schedule  Penalty) 
/ 

583$  ASSIGN:  SDD  contract  length=SDD  contract  length  +  PDR  Rework: 

SDD  Contract  End  Date=SDD  Contract  End  Date  +  PDR  Rework: 

SDD  contract  cost=SDD  contract  cost  +  (,1*SDD  contract  cost):NEXT(584$); 


Model  statements  for  module:  BasicProcess. Decide  212  (PDR  2) 
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584$  BRANCH,  1: 

With, (50)/100, 6624$, Yes: 

Else, 6625$, Yes; 

6624$  ASSIGN:  PDR  2.NumberOut  True=PDR  2.NumberOut  True  +  1:NEXT(592$); 
6625$  ASSIGN:  PDR  2.NumberOut  False=PDR  2.NumberOut  False  +  1:NEXT(649$); 


;  Model  statements  for  module:  BasicProcess. Assign  143  (Assign  PDR2  rework) 
/ 

649$  ASSIGN:  PDR  rework=.5*PDR  Rework:NEXT(585$); 


;  Model  statements  for  module:  BasicProcess. Process  255  (PDR  delay  2  PreC) 

/ 

585$  ASSIGN:  PDR  delay  2  PreC. Numberln=PDR  delay  2  PreC. Numberln  +  1: 

PDR  delay  2  PreC.WIP=PDR  delay  2  PreC.WIP+1; 

6627$  DELAY:  PDR  Rework,, VA; 

6674$  ASSIGN:  PDR  delay  2  PreC.NumberOut=PDR  delay  2  PreC.NumberOut  +  1: 

PDR  delay  2  PreC.WIP=PDR  delay  2  PreC.WIP-l:NEXT(586$); 


;  Model  statements  for  module:  BasicProcess. Assign  113  (Assign  PDR2  Cost  and  Schedule  Penalty) 
/ 

586$  ASSIGN:  SDD  contract  length=SDD  contract  length  +  PDR  Rework: 

SDD  Contract  End  Date=SDD  Contract  End  Date  +  PDR  Rework: 

SDD  contract  cost=SDD  contract  cost  +  (,1*SDD  contract  cost):NEXT(587$); 


;  Model  statements  for  module:  BasicProcess. Decide  213  (PDR  3) 
/ 

587$  BRANCH,  1: 

With, (90)/100, 6677$, Yes: 

Else, 6678$, Yes; 
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6677$  ASSIGN:  PDR  3.NumberOut  True=PDR  3.NumberOut  True  +  1:NEXT(592$); 
6678$  ASSIGN:  PDR  3.NumberOut  False=PDR  3.NumberOut  False  +  1:NEXT(588$); 


;  Model  statements  for  module:  BasicProcess. Process  256  (PDR  delay  3  PreC) 

/ 

588$  ASSIGN:  PDR  delay  3  PreC.Numberln=PDR  delay  3  PreC. Numberln  +  1: 

PDR  delay  3  PreC.WIP=PDR  delay  3  PreC.WIP+1; 

6680$  DELAY:  PDR  Rework,, VA; 

6727$  ASSIGN:  PDR  delay  3  PreC.NumberOut=PDR  delay  3  PreC.NumberOut  +  1: 

PDR  delay  3  PreC.WIP=PDR  delay  3  PreC.WIP-l:NEXT(591$); 


;  Model  statements  for  module:  BasicProcess. Assign  114  (Assign  PDR3  Cost  and  Schedule  Penalty) 
/ 

591$  ASSIGN:  SDD  contract  length=SDD  contract  length  +  PDR  Rework: 

SDD  Contract  End  Date=SDD  Contract  End  Date  +  PDR  Rework: 

SDD  contract  cost=SDD  contract  cost  +  (,1*SDD  contract  cost):NEXT(589$); 


;  Model  statements  for  module:  BasicProcess. Decide  214  (Final  PDR) 

/ 

589$  BRANCH,  1: 

With, (99)/100, 6730$, Yes: 

Else, 6731$, Yes; 

6730$  ASSIGN:  Final  PDR.NumberOut  True=Final  PDR.NumberOut  True  +  1:NEXT(592$); 

6731$  ASSIGN:  Final  PDR.NumberOut  False=Final  PDR.NumberOut  False  +  1:NEXT(639$); 


;  Model  statements  for  module:  BasicProcess. Assign  135  (Assign  program  kill  at  PDR) 
/ 

639$  ASSIGN:  TFIN=TNOW: 
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Program  Kill  time  at  PDR=TNOW:NEXT(672$); 


;  Model  statements  for  module:  BasicProcess. Record  16  (Record  16) 
/ 

672$  TALLY:  Record  16,INT(SimTime),l:NEXT(590$); 


;  Model  statements  for  module:  BasicProcess. Dispose  47  (Program  Kill  at  PDR) 

/ 

590$  ASSIGN:  Program  Kill  at  PDR.NumberOut=Program  Kill  at  PDR.NumberOut  +  1; 

6732$  DISPOSE:  No; 


;  Model  statements  for  module:  BasicProcess. Assign  91  (ACAT  I  Contract  Length  PreC) 
/ 

506$  ASSIGN:  SDD  Contract  Start=TNOW: 

SDD  contract  cost=l: 

SDD  original  contract  length=TRIA(365,  1980,  2190):NEXT(567$); 


;  Model  statements  for  module:  BasicProcess. Assign  92  (ACAT  II  Contract  Length  PreC) 
/ 

507$  ASSIGN:  SDD  contract  cost=l: 

SDD  Contract  Start=TNOW: 

SDD  original  contract  length=TRIA(365,1365,2190):NEXT(567$); 


;  Model  statements  for  module:  BasicProcess. Process  252  (Delay  to  Align  Funds  PreC) 

/ 

575$  ASSIGN:  Delay  to  Align  Funds  PreC.Numberln=Delay  to  Align  Funds  PreC.Numberln  +  1: 

Delay  to  Align  Funds  PreC.WIP=Delay  to  Align  Funds  PreC.WIP+1; 
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6734$  DELAY:  Triangular(30,35,75)„VA; 

6781$  ASSIGN:  Delay  to  Align  Funds  PreC.NumberOut=Delay  to  Align  Funds  PreC.NumberOut  + 

1: 

Delay  to  Align  Funds  PreC.WIP=Delay  to  Align  Funds  PreC.WIP-l:NEXT(501$); 


;  Model  statements  for  module:  BasicProcess. Decide  113  (Check  for  previous  MDA  decision  attempt 
preB) 

/ 

280$  BRANCH,  1: 

If, MS  B  approval  attempt==l, 6784$, Yes: 

Else, 6785$, Yes; 

6784$  ASSIGN:  Check  for  previous  MDA  decision  attempt  preB.NumberOut  True= 

Check  for  previous  MDA  decision  attempt  preB.NumberOut  True  +  1:NEXT(360$); 

6785$  ASSIGN:  Check  for  previous  MDA  decision  attempt  preB.NumberOut  False= 

Check  for  previous  MDA  decision  attempt  preB.NumberOut  False  +  1:NEXT(282$); 


;  Model  statements  for  module:  BasicProcess. Assign  66  (End  Simulation  PreB  4) 
/ 

360$  ASSIGN:  Kill  time  at  MS  B  decision=TNOW: 

TFIN=TNOW:NEXT(664$); 


;  Model  statements  for  module:  BasicProcess. Record  8  (Record  8) 
/ 

664$  TALLY:  Record  8,INT(SimTime),l:NEXT(281$); 


;  Model  statements  for  module:  BasicProcess. Dispose  23  (Kill  at  MS  B  decision) 

/ 

281$  ASSIGN:  Kill  at  MS  B  decision. NumberOut=Kill  at  MS  B  decision. NumberOut  +  1; 

6786$  DISPOSE:  No; 
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;  Model  statements  for  module:  BasicProcess. Assign  37  (Assign  counter  to  MDA  loop  preB) 
/ 

282$  ASSIGN:  MS  B  approval  attempt=l:NEXT(635$); 


;  Model  statements  for  module:  BasicProcess. Process  273  (Delay  to  repeat  required  steps  PreB) 

/ 

635$  ASSIGN:  Delay  to  repeat  required  steps  PreB.Numberln=Delay  to  repeat  required  steps 

PreB.Numberln  +  1: 

Delay  to  repeat  required  steps  PreB.WIP=Delay  to  repeat  required  steps  PreB.WIP+1; 
6788$  DELAY:  Triangular(60,120,180)„VA; 

6835$  ASSIGN:  Delay  to  repeat  required  steps  PreB.NumberOut=Delay  to  repeat  required  steps 

PreB.NumberOut  +  1: 

Delay  to  repeat  required  steps  PreB.WIP=Delay  to  repeat  required  steps  PreB.WIP- 

1:NEXT(279$); 


;  Model  statements  for  module:  BasicProcess. Process  120  (Independent  document  preB) 

/ 

248$  ASSIGN:  Independent  document  preB.Numberln=lndependent  document  preB.Numberln 

+  1: 

Independent  document  preB.WIP=lndependent  document  preB.WIP+l:NEXT(249$); 

249$  ASSIGN:  Draft  document  indep  preB.Numberln=Draft  document  indep  preB.Numberln  + 

1: 

Draft  document  indep  preB.WIP=Draft  document  indep  preB.WIP+1; 

6890$  DELAY:  Triangular(30,55,60)„VA; 

6937$  ASSIGN:  Draft  document  indep  preB.NumberOut=Draft  document  indep 

preB.NumberOut  +  1: 

Draft  document  indep  preB.WIP=Draft  document  indep  preB.WIP-l:NEXT(250$); 

250$  ASSIGN:  Air  staff  process  indep  preB.Numberln=Air  staff  process  indep  preB.Numberln  + 

1: 

Air  staff  process  indep  preB.WIP=Air  staff  process  indep  preB.WIP+1; 
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6941$  DELAY:  Triangular(21,29,42)„VA; 

6988$  ASSIGN:  Air  staff  process  indep  preB.NumberOut=Air  staff  process  indep 

preB.NumberOut  +  1: 

Air  staff  process  indep  preB.WIP=Air  staff  process  indep  preB.WIP-l:NEXT(251$); 

251$  BRANCH,  1: 

With, (95)/100, 6991$, Yes: 

Else, 6992$, Yes; 

6991$  ASSIGN:  Critical  comments  indep  preB.NumberOut  True=Critical  comments  indep 

preB.NumberOut  True  +  1 

:NEXT(252$); 

6992$  ASSIGN:  Critical  comments  indep  preB.NumberOut  False=Critical  comments  indep 

preB.NumberOut  False  +  1 

:NEXT(255$); 

252$  ASSIGN:  comment  resolution  indep  preB.Numberln=comment  resolution  indep 

preB.Numberln  +  1: 

comment  resolution  indep  preB.WIP=comment  resolution  indep  preB.WIP+1; 
6994$  DELAY:  Triangular(15,30,45)„VA; 

7041$  ASSIGN:  comment  resolution  indep  preB.NumberOut=comment  resolution  indep 

preB.NumberOut  +  1: 

comment  resolution  indep  preB.WIP=comment  resolution  indep  preB.WIP- 

1:NEXT(253$); 

253$  BRANCH,  1: 

With, (99)/100, 7044$, Yes: 

Else, 7045$, Yes; 

7044$  ASSIGN:  MAJCOM  approval  indep  preB.NumberOut  True=MAJCOM  approval  indep 

preB.NumberOut  True  +  1:NEXT(255$); 

7045$  ASSIGN:  MAJCOM  approval  indep  preB.NumberOut  False=MAJCOM  approval  indep 

preB.NumberOut  False  +  1 

:NEXT(254$); 

255$  ASSIGN:  AFROC  Preparations  indep  preB.Numberln=AFROC  Preparations  indep 

preB.Numberln  +  1: 

AFROC  Preparations  indep  preB.WIP=AFROC  Preparations  indep  preB.WIP+1; 
7047$  DELAY:  Triangular(30,45,60)„VA; 

7094$  ASSIGN:  AFROC  Preparations  indep  preB.NumberOut=AFROC  Preparations  indep 

preB.NumberOut  +  1: 
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AFROC  Preparations  indep  preB.WIP=AFROC  Preparations  indep  preB.WIP- 

1:NEXT(256$); 

256$  BRANCH,  1: 

With, (90)/100, 7097$, Yes: 

Else, 7098$, Yes; 

7097$  ASSIGN:  AFROC  decision  indep  preB.NumberOut  True=AFROC  decision  indep 

preB.NumberOut  True  +  1:NEXT(261$); 

7098$  ASSIGN:  AFROC  decision  indep  preB.NumberOut  False=AFROC  decision  indep 

preB.NumberOut  False  +  1:NEXT(260$); 

261$  BRANCH,  1: 

With, (25)/100, 7099$, Yes: 

Else, 7100$, Yes; 

7099$  ASSIGN:  Post  AFROC  actions  indep  preB.NumberOut  True=Post  AFROC  actions  indep 

preB.NumberOut  True  +  1 

:NEXT(262$); 

7100$  ASSIGN:  Post  AFROC  actions  indep  preB.NumberOut  False=Post  AFROC  actions  indep 

preB.NumberOut  False  +  1 

:NEXT(6886$); 

262$  ASSIGN:  Accomplish  Post  AFROC  actions  indep  preB.Numberln= 

Accomplish  Post  AFROC  actions  indep  preB.Numberln  +  1: 

Accomplish  Post  AFROC  actions  indep  preB.WIP=Accomplish  Post  AFROC  actions  indep 

preB.WIP+1; 

7102$  DELAY:  Triangular(l,ll,15)„VA; 

7149$  ASSIGN:  Accomplish  Post  AFROC  actions  indep  preB.NumberOut= 

Accomplish  Post  AFROC  actions  indep  preB.NumberOut  +  1: 

Accomplish  Post  AFROC  actions  indep  preB.WIP=Accomplish  Post  AFROC  actions  indep 

preB.WIP-1 

:NEXT(6886$); 

260$  BRANCH,  1: 

If, AFROC  Count  PreB==l, 7152$, Yes: 

Else, 7153$, Yes; 

7152$  ASSIGN:  Check  for  previous  path  indep  preB.NumberOut  True= 

Check  for  previous  path  indep  preB.NumberOut  True  +  1:NEXT(263$); 

7153$  ASSIGN:  Check  for  previous  path  indep  preB.NumberOut  False= 

Check  for  previous  path  indep  preB.NumberOut  False  +  1:NEXT(259$); 
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263$ 

ASSIGN: 

TFIN: 

Kill  time  at  AFROC  indep  PreB=TNOW: 

=TNOW:NEXT(264$); 

264$ 

TALLY: 

Record  23,INT(SimTime),l:NEXT(258$); 

258$ 

+ 1; 

ASSIGN: 

Death  at  AFROC  indep  preB.NumberOut=Death  at  AFROC  indep  preB.NumberOut 

7154$ 

DISPOSE: 

Yes; 

259$ 

ASSIGN: 

AFROC  Count  PreB=l:NEXT(257$); 

257$ 

BRANCH, 

1: 

With, (99)/100, 7155$, Yes: 

Else, 7156$, Yes; 

7155$  ASSIGN:  Dead  activity  indep  preB.NumberOut  True=Dead  activity  indep  preB.NumberOut 

True  +  1:NEXT(263$); 

7156$  ASSIGN:  Dead  activity  indep  preB.NumberOut  False=Dead  activity  indep 

preB.NumberOut  False  +  1:NEXT(252$); 

254$  ASSIGN:  Hold  for  a  year  later  in  process  indep  preB.Numberln= 

Hold  for  a  year  later  in  process  indep  preB.Numberln  +  1: 

Hold  for  a  year  later  in  process  indep  preB.WIP=Hold  for  a  year  later  in  process  indep 

preB.WIP+1; 

7158$  DELAY:  Triangular(270,300,365)„NVA; 

7205$  ASSIGN:  Hold  for  a  year  later  in  process  indep  preB.NumberOut= 

Hold  for  a  year  later  in  process  indep  preB.NumberOut  +  1: 

Hold  for  a  year  later  in  process  indep  preB.WIP=Hold  for  a  year  later  in  process  indep 

preB.WIP-1 

:NEXT(255$); 

6886$  ASSIGN:  Independent  document  preB.NumberOut=lndependent  document 

preB.NumberOut  +  1: 

Independent  document  preB.WIP=lndependent  document  preB.WIP-l:NEXT(221$); 


;  Model  statements  for  module:  BasicProcess. Process  107  (Joint  Integration  PreB) 

/ 

222$  ASSIGN:  Joint  Integration  PreB.Numberln=Joint  Integration  PreB.Numberln  +  1: 
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Joint  Integration  PreB.WIP=Joint  Integration  PreB.WIP+l:NEXT(223$); 


223$  ASSIGN:  Draft  document  joint  integ  preB.Numberln=Draft  document  joint  integ 

preB.Numberln  +  1: 

Draft  document  joint  integ  preB.WIP=Draft  document  joint  integ  preB.WIP+1; 

7260$  DELAY:  Triangular(30,55,60)„VA; 

7307$  ASSIGN:  Draft  document  joint  integ  preB.NumberOut=Draft  document  joint  integ 

preB.NumberOut  +  1: 

Draft  document  joint  integ  preB.WIP=Draft  document  joint  integ  preB.WIP- 

1:NEXT(224$); 

224$  ASSIGN:  Air  staff  process  joint  integ  preB.Numberln=Air  staff  process  joint  integ 

preB.Numberln  + 1: 

Air  staff  process  joint  integ  preB.WIP=Air  staff  process  joint  integ  preB.WIP+1; 

7311$  DELAY:  Triangular(21,29,42)„VA; 

7358$  ASSIGN:  Air  staff  process  joint  integ  preB.NumberOut=Air  staff  process  joint  integ 

preB.NumberOut  +  1: 

Air  staff  process  joint  integ  preB.WIP=Air  staff  process  joint  integ  preB.WIP- 

1:NEXT(225$); 

225$  BRANCH,  1: 

With, (95)/100, 7361$, Yes: 

Else, 7362$, Yes; 

7361$  ASSIGN:  Critical  comments  joint  integ  preB.NumberOut  True= 

Critical  comments  joint  integ  preB.NumberOut  True  +  1:NEXT(226$); 

7362$  ASSIGN:  Critical  comments  joint  integ  preB.NumberOut  False= 

Critical  comments  joint  integ  preB.NumberOut  False  +  1:NEXT(228$); 

226$  ASSIGN:  comment  resolution  joint  integ  preB.Numberln=comment  resolution  joint  integ 

preB.Numberln  +  1: 

comment  resolution  joint  integ  preB.WIP=comment  resolution  joint  integ  preB.WIP+1; 
7364$  DELAY:  Triangular(15,30,45)„VA; 

7411$  ASSIGN:  comment  resolution  joint  integ  preB.NumberOut=comment  resolution  joint 

integ  preB.NumberOut  +  1: 

comment  resolution  joint  integ  preB.WIP=comment  resolution  joint  integ  preB.WIP- 

1:NEXT(227$); 

227$  BRANCH,  1: 

With, (99)/100, 7414$, Yes: 

Else, 7415$, Yes; 
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7414$  ASSIGN:  MAJCOM  approval  joint  integ  preB.NumberOut  True=MAJCOM  approval  joint 

integ  preB.NumberOut  True  +  1 
:NEXT(228$); 

7415$  ASSIGN:  MAJCOM  approval  joint  integ  preB.NumberOut  False= 

MAJCOM  approval  joint  integ  preB.NumberOut  False  +  1:NEXT(234$); 

228$  BRANCH,  1: 

With, (50)/100, 7416$, Yes: 

Else, 7417$, Yes; 

7416$  ASSIGN:  Document  review  phase  joint  integ  preB.NumberOut  True= 

Document  review  phase  joint  integ  preB.NumberOut  True  +  1:NEXT(229$); 

7417$  ASSIGN:  Document  review  phase  joint  integ  preB.NumberOut  False= 

Document  review  phase  joint  integ  preB.NumberOut  False  +  1:NEXT(232$); 

229$  ASSIGN:  Document  review  phase  2  flag  level  joint  integ  preB.Numberln= 

Document  review  phase  2  flag  level  joint  integ  preB.Numberln  +  1: 

Document  review  phase  2  flag  level  joint  integ  preB.WIP= 

Document  review  phase  2  flag  level  joint  integ  preB.WIP+1; 

7419$  DELAY:  Triangular(21,34,42)„VA; 

7466$  ASSIGN:  Document  review  phase  2  flag  level  joint  integ  preB.NumberOut= 

Document  review  phase  2  flag  level  joint  integ  preB.NumberOut  +  1: 

Document  review  phase  2  flag  level  joint  integ  preB.WIP= 

Document  review  phase  2  flag  level  joint  integ  preB.WIP-l:NEXT(230$); 

230$  ASSIGN:  Resolving  flag  level  comments  joint  integ  preB.Numberln= 

Resolving  flag  level  comments  joint  integ  preB.Numberln  +  1: 

Resolving  flag  level  comments  joint  integ  preB.WIP= 

Resolving  flag  level  comments  joint  integ  preB.WIP+1; 

7470$  DELAY:  Triangular(15,28,30)„VA; 

7517$  ASSIGN:  Resolving  flag  level  comments  joint  integ  preB.NumberOut= 

Resolving  flag  level  comments  joint  integ  preB.NumberOut  +  1: 

Resolving  flag  level  comments  joint  integ  preB.WIP= 

Resolving  flag  level  comments  joint  integ  preB.WIP-l:NEXT(231$); 

231$  BRANCH,  1: 

With, (99)/100, 7520$, Yes: 

Else, 7521$, Yes; 

7520$  ASSIGN:  MAJCOM  approval  later  on  joint  integ  preB.NumberOut  True= 

MAJCOM  approval  later  on  joint  integ  preB.NumberOut  True  +  1:NEXT(232$); 
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7521$  ASSIGN:  MAJCOM  approval  later  on  joint  integ  preB.NumberOut  False= 

MAJCOM  approval  later  on  joint  integ  preB.NumberOut  False  +  1:NEXT(235$); 

232$  ASSIGN:  Interoperability  Certification  joint  integ  preB.Numberln= 

Interoperability  Certification  joint  integ  preB.Numberln  +  1: 

Interoperability  Certification  joint  integ  preB.WIP= 

Interoperability  Certification  joint  integ  preB.WIP+1; 

7523$  DELAY:  Triangular(10,15,20)„VA; 

7570$  ASSIGN:  Interoperability  Certification  joint  integ  preB.NumberOut= 

Interoperability  Certification  joint  integ  preB.NumberOut  +  1: 

Interoperability  Certification  joint  integ  preB.WIP= 

Interoperability  Certification  joint  integ  preB.WIP-l:NEXT(233$); 

233$  ASSIGN:  AFROC  Preparations  joint  integ  preB.Numberln=AFROC  Preparations  joint  integ 

preB.Numberln  +  1: 

AFROC  Preparations  joint  integ  preB.WIP=AFROC  Preparations  joint  integ  preB.WIP+1; 
7574$  DELAY:  Triangular(30,45,60)„VA; 

7621$  ASSIGN:  AFROC  Preparations  joint  integ  preB.NumberOut=AFROC  Preparations  joint 

integ  preB.NumberOut  +  1: 

AFROC  Preparations  joint  integ  preB.WIP=AFROC  Preparations  joint  integ  preB.WIP- 

1:NEXT(236$); 

236$  BRANCH,  1: 

With, (90)/100, 7624$, Yes: 

Else, 7625$, Yes; 

7624$  ASSIGN:  AFROC  decision  joint  integ  preB.NumberOut  True=AFROC  decision  joint  integ 

preB.NumberOut  True  +  1 

:NEXT(241$); 

7625$  ASSIGN:  AFROC  decision  joint  integ  preB.NumberOut  False=AFROC  decision  joint  integ 

preB.NumberOut  False  +  1 

:NEXT(240$); 

241$  BRANCH,  1: 

With, (25)/100, 7626$, Yes: 

Else, 7627$, Yes; 

7626$  ASSIGN:  Post  AFROC  actions  joint  integ  preB.NumberOut  True= 

Post  AFROC  actions  joint  integ  preB.NumberOut  True  +  1:NEXT(242$); 

7627$  ASSIGN:  Post  AFROC  actions  joint  integ  preB.NumberOut  False= 

Post  AFROC  actions  joint  integ  preB.NumberOut  False  +  1:NEXT(243$); 
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242$  ASSIGN:  Accomplish  Post  AFROC  actions  joint  integ  preB.Numberln= 

Accomplish  Post  AFROC  actions  joint  integ  preB.Numberln  +  1: 

Accomplish  Post  AFROC  actions  joint  integ  preB.WIP= 

Accomplish  Post  AFROC  actions  joint  integ  preB.WIP+1; 

7629$  DELAY:  Triangular(l,ll,15)„VA; 

7676$  ASSIGN:  Accomplish  Post  AFROC  actions  joint  integ  preB.NumberOut= 

Accomplish  Post  AFROC  actions  joint  integ  preB.NumberOut  +  1: 

Accomplish  Post  AFROC  actions  joint  integ  preB.WIP= 

Accomplish  Post  AFROC  actions  joint  integ  preB.WIP-l:NEXT(243$); 

243$  ASSIGN:  document  signing  and  validation  joint  integ  preB.Numberln= 

document  signing  and  validation  joint  integ  preB.Numberln  +  1: 
document  signing  and  validation  joint  integ  preB.WIP= 
document  signing  and  validation  joint  integ  preB.WIP+1; 

7680$  DELAY:  Triangular(14,26,30)„VA; 

7727$  ASSIGN:  document  signing  and  validation  joint  integ  preB.NumberOut= 

document  signing  and  validation  joint  integ  preB.NumberOut  +  1: 
document  signing  and  validation  joint  integ  preB.WIP= 
document  signing  and  validation  joint  integ  preB.WIP-l:NEXT(244$); 

244$  BRANCH,  1: 

With, (99)/100, 7730$, Yes: 

Else, 7731$, Yes; 

7730$  ASSIGN:  Final  AFROC  approval  joint  integ  preB.NumberOut  True= 

Final  AFROC  approval  joint  integ  preB.NumberOut  True  +  1:NEXT(7256$); 

7731$  ASSIGN:  Final  AFROC  approval  joint  integ  preB.NumberOut  False= 

Final  AFROC  approval  joint  integ  preB.NumberOut  False  +  1:NEXT(245$); 

245$  ASSIGN:  Final  AFROC  resolution  joint  integ  preB.Numberln= 

Final  AFROC  resolution  joint  integ  preB.Numberln  +  1: 

Final  AFROC  resolution  joint  integ  preB.WIP=Final  AFROC  resolution  joint  integ 

preB.WIP+1; 

7733$  DELAY:  Triangular(42,48,60)„VA; 

7780$  ASSIGN:  Final  AFROC  resolution  joint  integ  preB.NumberOut= 

Final  AFROC  resolution  joint  integ  preB.NumberOut  +  1: 

Final  AFROC  resolution  joint  integ  preB.WIP=Final  AFROC  resolution  joint  integ 

preB.WIP-1 

:NEXT(7256$); 

240$  BRANCH,  1: 

If, AFROC  Count  PreB==l, 7783$, Yes: 
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Else, 7784$, Yes; 

7783$  ASSIGN:  Check  for  previous  path  joint  integ  preB.NumberOut  True= 

Check  for  previous  path  joint  integ  preB.NumberOut  True  +  1:NEXT(246$); 

7784$  ASSIGN:  Check  for  previous  path  joint  integ  preB.NumberOut  False= 

Check  for  previous  path  joint  integ  preB.NumberOut  False  +  1:NEXT(239$); 

246$  ASSIGN:  Kill  time  at  AFROC  joint  integ  PreB=TNOW: 

TFIN=TNOW:NEXT(247$); 

247$  TALLY:  Record  22,INT(SimTime),l:NEXT(238$); 

238$  ASSIGN:  Death  at  AFROC  joint  integ  preB.NumberOut=Death  at  AFROC  joint  integ 

preB.NumberOut  +  1; 

7785$  DISPOSE:  Yes; 

239$  ASSIGN:  AFROC  Count  PreB=l:NEXT(237$); 

237$  BRANCH,  1: 

With, (99)/100, 7786$, Yes: 

Else, 7787$, Yes; 

7786$  ASSIGN:  Dead  activity  joint  integ  preB.NumberOut  True=Dead  activity  joint  integ 

preB.NumberOut  True  +  1 

:NEXT(246$); 

7787$  ASSIGN:  Dead  activity  joint  integ  preB.NumberOut  False=Dead  activity  joint  integ 

preB.NumberOut  False  +  1 

:NEXT(226$); 

235$  ASSIGN:  Hold  for  a  year  later  in  process  2nd  time  joint  integ  preB.Numberln= 

Hold  for  a  year  later  in  process  2nd  time  joint  integ  preB.Numberln  +  1: 

Hold  for  a  year  later  in  process  2nd  time  joint  integ  preB.WIP= 

Hold  for  a  year  later  in  process  2nd  time  joint  integ  preB.WIP+1; 

7789$  DELAY:  Triangular(270,300,365)„NVA; 

7836$  ASSIGN:  Hold  for  a  year  later  in  process  2nd  time  joint  integ  preB.NumberOut= 

Hold  for  a  year  later  in  process  2nd  time  joint  integ  preB.NumberOut  +  1: 

Hold  for  a  year  later  in  process  2nd  time  joint  integ  preB.WIP= 

Hold  for  a  year  later  in  process  2nd  time  joint  integ  preB.WIP-l:NEXT(232$); 

234$  ASSIGN:  Hold  for  a  year  later  in  process  joint  integ  preB.Numberln= 

Hold  for  a  year  later  in  process  joint  integ  preB.Numberln  +  1: 

Hold  for  a  year  later  in  process  joint  integ  preB.WIP= 
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Hold  for  a  year  later  in  process  joint  integ  preB.WIP+1; 

7840$  DELAY:  Triangular(270,300,365)„NVA; 

7887$  ASSIGN:  Hold  for  a  year  later  in  process  joint  integ  preB.NumberOut= 

Hold  for  a  year  later  in  process  joint  integ  preB.NumberOut  +  1: 

Hold  for  a  year  later  in  process  joint  integ  preB.WIP= 

Hold  for  a  year  later  in  process  joint  integ  preB.WIP-l:NEXT(228$); 

7256$  ASSIGN:  Joint  Integration  PreB.NumberOut=Joint  Integration  PreB.NumberOut  +  1: 

Joint  Integration  PreB.WIP=Joint  Integration  PreB.WIP-l:NEXT(221$); 


;  Model  statements  for  module:  BasicProcess. Decide  72  (Check  Condition  PreB) 

/ 

187$  BRANCH,  1: 

If,  RequirementPathTrack>= 1,7890$, Yes: 

Else, 7891$, Yes; 

7890$  ASSIGN:  Check  Condition  PreB.NumberOut  True=Check  Condition  PreB.NumberOut  True 

+  1:NEXT(674$); 

7891$  ASSIGN:  Check  Condition  PreB.NumberOut  False=Check  Condition  PreB.NumberOut  False 

+  1:NEXT(186$); 


;  Model  statements  for  module:  BasicProcess. Record  33  (Record  33) 
/ 

674$  TALLY:  Record  33, INT(SimTime),l:NEXT(176$); 


;  Model  statements  for  module:  BasicProcess. Assign  23  (end  simulation  PreB) 
/ 

176$  ASSIGN:  Kill  at  begin  of  requirements  swimlane  PreB=l: 

TFIN=TNOW:NEXT(18$); 
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;  Model  statements  for  module:  BasicProcess. Dispose  5  (End  prior  to  start  of  Requirements  swimlane 
PreB) 

/ 

18$  ASSIGN:  End  prior  to  start  of  Requirements  swimlane  PreB.NumberOut= 

End  prior  to  start  of  Requirements  swimlane  PreB.NumberOut  +  1; 

7892$  DISPOSE:  No; 


;  Model  statements  for  module:  BasicProcess. Assign  25  (Add  counter  through  feedback  path  PreB) 
/ 

186$  ASSIGN:  RequirementPathTrackPreB=RequirementPathTrackPreB  +  1:NEXT(185$); 


;  Model  statements  for  module:  BasicProcess. Decide  71  (Decision  to  Repursue  PreB) 

/ 

185$  BRANCH,  1: 

With, (85)/100, 7893$, Yes: 

Else, 7894$, Yes; 

7893$  ASSIGN:  Decision  to  Repursue  PreB.NumberOut  True=Decision  to  Repursue 

PreB.NumberOut  True  +  1:NEXT(188$); 

7894$  ASSIGN:  Decision  to  Repursue  PreB.NumberOut  False=Decision  to  Repursue 

PreB.NumberOut  False  +  1:NEXT(675$); 


;  Model  statements  for  module:  BasicProcess. Process  89  (Update  Briefing  Materials  PreB) 

/ 

188$  ASSIGN:  Update  Briefing  Materials  PreB.Numberln=Update  Briefing  Materials 

PreB.Numberln  +  1: 

Update  Briefing  Materials  PreB.WIP=Update  Briefing  Materials  PreB.WIP+1; 

7896$  DELAY:  Triangular(10,35,40)„VA; 

7943$  ASSIGN:  Update  Briefing  Materials  PreB.NumberOut=Update  Briefing  Materials 

PreB.NumberOut  +  1: 

Update  Briefing  Materials  PreB.WIP=Update  Briefing  Materials  PreB.WIP-l:NEXT(180$); 
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Model  statements  for  module:  BasicProcess. Record  34  (Record  34) 


675$  TALLY:  Record  34,INT(SimTime),l:NEXT(176$); 


;  Model  statements  for  module:  BasicProcess. Decide  65  (Check  on  conditions) 

/ 

175$  BRANCH,  1: 

lf,PreBpursuerequirements==l,7946$,Yes: 

Else, 7947$, Yes; 

7946$  ASSIGN:  Check  on  conditions. NumberOut  True=Check  on  conditions. NumberOut  True  + 

1:NEXT(659$); 

7947$  ASSIGN:  Check  on  conditions. NumberOut  False=Check  on  conditions. NumberOut  False  + 

1:NEXT(177$); 


;  Model  statements  for  module:  BasicProcess. Record  3  (Record  3) 
/ 

659$  TALLY:  Record  3,INT(SimTime),l:NEXT(176$); 


;  Model  statements  for  module:  BasicProcess. Assign  24  (Set  check  on  decision  variable) 
/ 

177$  ASSIGN:  PreBpursuerequirements=l:NEXT(178$); 


;  Model  statements  for  module:  BasicProcess. Process  80  (Wait  for  more  favorable  conditions) 

/ 

178$  ASSIGN:  Wait  for  more  favorable  conditions. Numberln=Wait  for  more  favorable 

conditions. Numberln  +  1: 

Wait  for  more  favorable  conditions. WIP=Wait  for  more  favorable  conditions. WIP+1; 
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7949$  DELAY:  Triangular(100, 115,150), ,VA; 

7996$  ASSIGN:  Wait  for  more  favorable  conditions. NumberOut=Wait  for  more  favorable 

conditions.  NumberOut  +  1: 

Wait  for  more  favorable  conditions. WIP=Wait  for  more  favorable  conditions. WIP- 

1:NEXT(174$); 


;  Model  statements  for  module:  BasicProcess. Process  146  (RFP  Release  and  Source  Selection  PreB) 
/ 

284$  ASSIGN:  RFP  Release  and  Source  Selection  PreB.Numberln=RFP  Release  and  Source 

Selection  PreB.Numberln  +  1: 

RFP  Release  and  Source  Selection  PreB.WIP=RFP  Release  and  Source  Selection 

PreB.WIP+1; 

8000$  DELAY:  Triangular(90,160,180)„VA; 

8047$  ASSIGN:  RFP  Release  and  Source  Selection  PreB.NumberOut=RFP  Release  and  Source 

Selection  PreB. NumberOut  +  1: 

RFP  Release  and  Source  Selection  PreB.WIP=RFP  Release  and  Source  Selection 
PreB.WIP-l:NEXT(285$); 


;  Model  statements  for  module:  BasicProcess. Decide  114  (Protest  award  PreB) 

/ 

285$  BRANCH,  1: 

With, (20)/100, 8050$, Yes: 

Else, 8051$, Yes; 

8050$  ASSIGN:  Protest  award  PreB. NumberOut  True=Protest  award  PreB. NumberOut  True  + 

1:NEXT(287$); 

8051$  ASSIGN:  Protest  award  PreB. NumberOut  False=Protest  award  PreB. NumberOut  False  + 

1:NEXT(286$); 


;  Model  statements  for  module:  BasicProcess. Process  148  (Delay  for  Protest  review  PreB) 

/ 

287$  ASSIGN:  Delay  for  Protest  review  PreB.Numberln=Delay  for  Protest  review  PreB.Numberln 

+  1: 
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Delay  for  Protest  review  PreB.WIP=Delay  for  Protest  review  PreB.WIP+1; 

8053$  DELAY:  Triangular(30,50,60)„VA; 

8100$  ASSIGN:  Delay  for  Protest  review  PreB.NumberOut=Delay  for  Protest  review 

PreB.NumberOut  +  1: 

Delay  for  Protest  review  PreB.WIP=Delay  for  Protest  review  PreB.WIP-l:NEXT(288$); 


;  Model  statements  for  module:  BasicProcess. Decide  115  (Protest  upheld) 

/ 

288$  BRANCH,  1: 

With, (40)/100, 8103$, Yes: 

Else, 8104$, Yes; 

8103$  ASSIGN:  Protest  upheld. NumberOut  True=Protest  upheld. NumberOut  True  + 

1:NEXT(284$); 

8104$  ASSIGN:  Protest  upheld. NumberOut  False=Protest  upheld. NumberOut  False  + 

1:NEXT(286$); 


;  Model  statements  for  module:  BasicProcess. Process  147  (Scope  and  Award  Technology 
Development  Contracts) 


286$ 


8106$ 

8153$ 


ASSIGN: 

Scope 

Scope 

Scope 

DELAY: 

ASSIGN: 

Scope 

Scope 

Scope 


Scope  and  Award  Technology  Development  Contracts. Numberln= 
and  Award  Technology  Development  Contracts. Numberln  +  1: 
and  Award  Technology  Development  Contracts. WIP= 
and  Award  Technology  Development  Contracts. WIP+1; 

T  riangular(30,100,120)„VA; 

Scope  and  Award  Technology  Development  Contracts. NumberOut= 
and  Award  Technology  Development  Contracts. NumberOut  +  1: 
and  Award  Technology  Development  Contracts. WIP= 
and  Award  Technology  Development  Contracts. WIP-1:NEXT(292$); 


;  Model  statements  for  module:  BasicProcess. Decide  116  (Path  depends  upon  ACAT  level  PreB) 
/ 

292$  BRANCH,  1: 
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lf,ACAT  Level==l,289$,Yes: 
lf,ACAT  Level==2,290$,Yes: 
Else, 291$, Yes; 


;  Model  statements  for  module:  BasicProcess. Assign  41  (ACAT  III  Contract  Length) 
/ 

291$  ASSIGN:  contract  cost=l: 

TD  Contract  Start=TNOW: 

TD  original  contract  length=TRIA(365,  480,  2190):NEXT(371$); 


;  Model  statements  for  module:  BasicProcess. Assign  71  (Determine  contract  end  date) 

/ 

371$  ASSIGN:  TD  Contract  length=TD  original  contract  length: 

TD  Contract  End  Date=TD  Contract  Start  +  TD  original  contract  length:NEXT(293$); 


;  Model  statements  for  module:  BasicProcess. Separate  11  (Split  flow  PreB) 

/ 

293$  DUPLICATE,  100-0: 

1,8160$,0:NEXT(8159$); 

8159$  ASSIGN:  Split  flow  PreB.NumberOut  Orig=Split  flow  PreB.NumberOut  Orig  + 

1:NEXT(368$); 

8160$  ASSIGN:  Split  flow  PreB.NumberOut  Dup=Split  flow  PreB.NumberOut  Dup  + 

1:NEXT(313$); 


;  Model  statements  for  module:  AdvancedProcess.Hold  8  (Wait  for  signal  for  Costing  and  Acquisition 
Planning  activities  PreB) 

/ 

368$  QUEUE,  Wait  for  signal  for  Costing  and  Acquisition  Planning  activities  PreB. Queue; 

SCAN:  Acq  Plan  PreB==l:NEXT(367$); 
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;  Model  statements  for  module:  BasicProcess. Separate  19  (Split  into  Acq  Planning  and  Costing 
Activities) 

/ 

367$  DUPLICATE,  100-0: 

1,8163$,0:NEXT(8162$); 

8162$  ASSIGN:  Split  into  Acq  Planning  and  Costing  Activities. NumberOut  Orig= 

Split  into  Acq  Planning  and  Costing  Activities. NumberOut  Orig  +  1:NEXT(342$); 

8163$  ASSIGN:  Split  into  Acq  Planning  and  Costing  Activities. NumberOut  Dup= 

Split  into  Acq  Planning  and  Costing  Activities. NumberOut  Dup  +  1:NEXT(309$); 


;  Model  statements  for  module:  BasicProcess. Separate  16  (Split  into  costing  activities  PreB) 
/ 

342$  DUPLICATE,  100-0: 

1,8166$,0:NEXT(8165$); 

8165$  ASSIGN:  Split  into  costing  activities  PreB. NumberOut  Orig= 

Split  into  costing  activities  PreB. NumberOut  Orig  +  1:NEXT(343$); 

8166$  ASSIGN:  Split  into  costing  activities  PreB. NumberOut  Dup= 

Split  into  costing  activities  PreB. NumberOut  Dup  +  1:NEXT(344$); 


;  Model  statements  for  module:  BasicProcess. Separate  17  (Second  split  into  costing  activities  PreB) 
/ 

343$  DUPLICATE,  100-0: 

1,8169$,0:NEXT(8168$); 

8168$  ASSIGN:  Second  split  into  costing  activities  PreB. NumberOut  Orig= 

Second  split  into  costing  activities  PreB. NumberOut  Orig  +  1:NEXT(345$); 

8169$  ASSIGN:  Second  split  into  costing  activities  PreB. NumberOut  Dup= 
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Second  split  into  costing  activities  PreB.NumberOut  Dup  +  1:NEXT(346$); 


;  Model  statements  for  module:  BasicProcess. Process  173  (Contractor  cost  estimate  PreB) 

/ 

345$  ASSIGN:  Contractor  cost  estimate  PreB. Numberln=Contractor  cost  estimate 

PreB.Numberln  +  1: 

Contractor  cost  estimate  PreB.WIP=Contractor  cost  estimate  PreB.WIP+1; 

8171$  DELAY:  Triangular(45,50,90)„VA; 

8218$  ASSIGN:  Contractor  cost  estimate  PreB. NumberOut=Contractor  cost  estimate 

PreB.NumberOut  +  1: 

Contractor  cost  estimate  PreB.WIP=Contractor  cost  estimate  PreB.WIP-l:NEXT(347$); 


;  Model  statements  for  module:  BasicProcess. Batch  13  (for  Affordability  Assessment  PreB) 

/ 

347$  QUEUE,  for  Affordability  Assessment  PreB. Queue; 

8221$  GROUP,  , Permanent^, Last:NEXT(8222$); 

8222$  ASSIGN:  for  Affordability  Assessment  PreB.NumberOut=for  Affordability  Assessment 

PreB.NumberOut  +  1 

:NEXT(348$); 


;  Model  statements  for  module:  BasicProcess. Process  175  (Affordability  Assessment  PreB) 

/ 

348$  ASSIGN:  Affordability  Assessment  PreB. Numberln=Affordability  Assessment 

PreB.Numberln  +  1: 

Affordability  Assessment  PreB.WIP=Affordability  Assessment  PreB.WIP+1; 

8224$  DELAY:  Triangular(120,160,180)„VA; 

8271$  ASSIGN:  Affordability  Assessment  PreB. NumberOut=Affordability  Assessment 

PreB.NumberOut  +  1: 

Affordability  Assessment  PreB.WIP=Affordability  Assessment  PreB.WIP-l:NEXT(349$); 
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;  Model  statements  for  module:  BasicProcess. Separate  18  (for  funding  check) 

/ 

349$  DUPLICATE,  100-0: 

1,8276$,0:NEXT(8275$); 

8275$  ASSIGN:  for  funding  check. NumberOut  Orig=for  funding  check. NumberOut  Orig  + 

1:NEXT(265$); 

8276$  ASSIGN:  for  funding  check. NumberOut  Dup=for  funding  check. NumberOut  Dup  + 

1:NEXT(341$); 


;  Model  statements  for  module:  BasicProcess. Decide  106  (Funds  set  aside  for  next  phase  in  FYDP  at 
80  percent  of  ICE  amount  PreB) 

/ 

265$  BRANCH,  1: 

With, (70)/100, 8277$, Yes: 

Else, 8278$, Yes; 

8277$  ASSIGN:  Funds  set  aside  for  next  phase  in  FYDP  at  80  percent  of  ICE  amount 

PreB. NumberOut  True= 

Funds  set  aside  for  next  phase  in  FYDP  at  80  percent  of  ICE  amount  PreB. NumberOut 

True  +  1 

:NEXT(351$); 


8278$  ASSIGN:  Funds  set  aside  for  next  phase  in  FYDP  at  80  percent  of  ICE  amount 

PreB. NumberOut  False= 

Funds  set  aside  for  next  phase  in  FYDP  at  80  percent  of  ICE  amount  PreB. NumberOut 

False  +  1 


:NEXT(268$); 


;  Model  statements  for  module:  AdvancedProcess.Hold  3  (KPPs  arrive  from  Requirements) 
/ 

351$  QUEUE,  KPPs  arrive  from  Requirements. Queue; 

SCAN:  KPPs  Ready  PreB==l:NEXT(350$); 
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Model  statements  for  module:  BasicProcess. Process  176  (Set  Acquisition  Program  Baseline  PreB) 


350$  ASSIGN:  Set  Acquisition  Program  Baseline  PreB. Numberln=Set  Acquisition  Program 

Baseline  PreB.Numberln  + 1: 

Set  Acquisition  Program  Baseline  PreB.WIP=Set  Acquisition  Program  Baseline 

PreB.WIP+1; 

8280$  DELAY:  Triangular(10,25,30)„VA; 

8327$  ASSIGN:  Set  Acquisition  Program  Baseline  PreB. NumberOut=Set  Acquisition  Program 

Baseline  PreB.NumberOut  +  1: 

Set  Acquisition  Program  Baseline  PreB.WIP=Set  Acquisition  Program  Baseline  PreB.WIP- 

1:NEXT(277$); 


;  Model  statements  for  module:  BasicProcess. Batch  8  (Complete  predecessor  activities  preB) 

/ 

277$  QUEUE,  Complete  predecessor  activities  preB. Queue; 

8330$  GROUP,  , Permanent^, Last:NEXT(8331$); 

8331$  ASSIGN:  Complete  predecessor  activities  preB.NumberOut=Complete  predecessor 

activities  preB.NumberOut  +  1 
:NEXT(275$); 


;  Model  statements  for  module:  BasicProcess. Decide  111  (ACAT  level  check  preB) 

/ 

275$  BRANCH,  1: 

If, ACAT  Level==l, 8332$, Yes: 

Else, 8333$, Yes; 

8332$  ASSIGN:  ACAT  level  check  preB.NumberOut  True=ACAT  level  check  preB.NumberOut 

True  +  1:NEXT(274$); 

8333$  ASSIGN:  ACAT  level  check  preB.NumberOut  False=ACAT  level  check  preB.NumberOut 

False  +  1:NEXT(276$); 
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;  Model  statements  for  module:  BasicProcess. Process  143  (ACAT  1  Preparation  for  Acquisition  Panels 
preB) 

/ 

274$  ASSIGN:  ACAT  1  Preparation  for  Acquisition  Panels  preB.Numberln= 

ACAT  1  Preparation  for  Acquisition  Panels  preB.Numberln  +  1: 

ACAT  1  Preparation  for  Acquisition  Panels  preB.WIP= 

ACAT  1  Preparation  for  Acquisition  Panels  preB.WIP+1; 

8335$  DELAY:  Triangular(40,56,60)„VA; 

8382$  ASSIGN:  ACAT  1  Preparation  for  Acquisition  Panels  preB.NumberOut= 

ACAT  1  Preparation  for  Acquisition  Panels  preB.NumberOut  +  1: 

ACAT  1  Preparation  for  Acquisition  Panels  preB.WIP= 

ACAT  1  Preparation  for  Acquisition  Panels  preB.WIP-l:NEXT(278$); 


;  Model  statements  for  module:  BasicProcess. Process  145  (Acquisition  Panels  PreB) 

/ 

278$  ASSIGN:  Acquisition  Panels  PreB.Numberln=Acquisition  Panels  PreB.Numberln  +  1: 

Acquisition  Panels  PreB.WIP=Acquisition  Panels  PreB.WIP+1; 

8386$  DELAY:  Triangular(15,30,35)„VA; 

8433$  ASSIGN:  Acquisition  Panels  PreB.NumberOut=Acquisition  Panels  PreB.NumberOut  +  1: 

Acquisition  Panels  PreB.WIP=Acquisition  Panels  PreB.WIP-l:NEXT(353$); 


;  Model  statements  for  module:  BasicProcess. Process  144  (ACAT  II  or  III  Preparation  for  Acquisition 
Panels  preB) 

/ 

276$  ASSIGN:  ACAT  II  or  III  Preparation  for  Acquisition  Panels  preB.Numberln= 

ACAT  II  or  III  Preparation  for  Acquisition  Panels  preB.Numberln  +  1: 

ACAT  II  or  III  Preparation  for  Acquisition  Panels  preB.WIP= 

ACAT  II  or  III  Preparation  for  Acquisition  Panels  preB.WIP+1; 

8437$  DELAY:  Triangular(15,25,30)„VA; 

8484$  ASSIGN:  ACAT  II  or  III  Preparation  for  Acquisition  Panels  preB.NumberOut= 

ACAT  II  or  III  Preparation  for  Acquisition  Panels  preB.NumberOut  +  1: 

ACAT  II  or  III  Preparation  for  Acquisition  Panels  preB.WIP= 

ACAT  II  or  III  Preparation  for  Acquisition  Panels  preB.WIP-l:NEXT(278$); 
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Model  statements  for  module:  BasicProcess. Decide  107  (ACAT  level  preB) 


268$  BRANCH,  1: 

If, ACAT  Level==l, 8487$, Yes: 

Else, 8488$, Yes; 

8487$  ASSIGN:  ACAT  level  preB.NumberOut  True=ACAT  level  preB.NumberOut  True  + 

1:NEXT(266$); 

8488$  ASSIGN:  ACAT  level  preB.NumberOut  False=ACAT  level  preB.NumberOut  False  + 

1:NEXT(267$); 


;  Model  statements  for  module:  BasicProcess. Process  133  (ACAT  I  time  delay  PreB) 

/ 

266$  ASSIGN:  ACAT  I  time  delay  PreB.Numberln=ACAT  I  time  delay  PreB.Numberln  +  1: 

ACAT  I  time  delay  PreB.WIP=ACAT  I  time  delay  PreB.WIP+1; 

8490$  DELAY:  Triangular(30,120,180)„VA; 

8537$  ASSIGN:  ACAT  I  time  delay  PreB.NumberOut=ACAT  I  time  delay  PreB.NumberOut  +  1: 

ACAT  I  time  delay  PreB.WIP=ACAT  I  time  delay  PreB.WIP-l:NEXT(351$); 


;  Model  statements  for  module:  BasicProcess. Process  134  (ACAT  II  or  ACAT  III  time  delay  PreB) 

/ 

267$  ASSIGN:  ACAT  II  or  ACAT  III  time  delay  PreB.Numberln=ACAT  II  or  ACAT  III  time  delay 

PreB.Numberln  +  1: 

ACAT  II  or  ACAT  III  time  delay  PreB.WIP=ACAT  II  or  ACAT  III  time  delay  PreB.WIP+1; 
8541$  DELAY:  Triangular(90,225,270)„VA; 

8588$  ASSIGN:  ACAT  II  or  ACAT  III  time  delay  PreB.NumberOut=ACAT  II  or  ACAT  III  time  delay 

PreB.NumberOut  +  1: 

ACAT  II  or  ACAT  III  time  delay  PreB.WIP=ACAT  II  or  ACAT  III  time  delay  PreB.WIP- 

1:NEXT(351$); 


Model  statements  for  module:  BasicProcess. Batch  12  (Bring  three  processes  together  PreB) 
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341$  QUEUE,  Bring  three  processes  together  PreB. Queue; 

8591$  GROUP,  , Permanent^, Last:NEXT(8592$); 

8592$  ASSIGN:  Bring  three  processes  together  PreB.NumberOut=Bring  three  processes  together 

PreB.NumberOut  +  1 

:NEXT(277$); 


;  Model  statements  for  module:  BasicProcess. Process  174  (Independent  Cost  Estimate  PreB) 

/ 

346$  ASSIGN:  Independent  Cost  Estimate  PreB.Numberln=lndependent  Cost  Estimate 

PreB.Numberln  +  1: 

Independent  Cost  Estimate  PreB.WIP=lndependent  Cost  Estimate  PreB.WIP+1; 
8594$  DELAY:  Triangular(30,35,60)„VA; 

8641$  ASSIGN:  Independent  Cost  Estimate  PreB.NumberOut=lndependent  Cost  Estimate 

PreB.NumberOut  +  1: 

Independent  Cost  Estimate  PreB.WIP=lndependent  Cost  Estimate  PreB.WIP- 

1:NEXT(347$); 


;  Model  statements  for  module:  BasicProcess. Process  172  (Program  Office  Cost  Estimate  PreB) 

/ 

344$  ASSIGN:  Program  Office  Cost  Estimate  PreB.Numberln=Program  Office  Cost  Estimate 

PreB.Numberln  +  1: 

Program  Office  Cost  Estimate  PreB.WIP=Program  Office  Cost  Estimate  PreB.WIP+1; 
8645$  DELAY:  Triangular(60,65,90)„VA; 

8692$  ASSIGN:  Program  Office  Cost  Estimate  PreB.NumberOut=Program  Office  Cost  Estimate 

PreB.NumberOut  +  1: 

Program  Office  Cost  Estimate  PreB.WIP=Program  Office  Cost  Estimate  PreB.WIP- 

1:NEXT(347$); 


Model  statements  for  module:  BasicProcess. Process  157  (Acquisition  Planning  Activities  PreB) 
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309$  ASSIGN:  Acquisition  Planning  Activities  PreB.Numberln=Acquisition  Planning  Activities 

PreB.Numberln  +  1: 

Acquisition  Planning  Activities  PreB.WIP=Acquisition  Planning  Activities 
PreB.WIP+l:NEXT(310$); 

310$  BRANCH,  1: 

lf,ACAT  Level==l, 8746$, Yes: 

Else, 8747$, Yes; 

8746$  ASSIGN:  Acq  planning  activities  depend  upon  ACAT  level  preB.NumberOut  True= 

Acq  planning  activities  depend  upon  ACAT  level  preB.NumberOut  True  +  1:NEXT(311$); 

8747$  ASSIGN:  Acq  planning  activities  depend  upon  ACAT  level  preB.NumberOut  False= 

Acq  planning  activities  depend  upon  ACAT  level  preB.NumberOut  False  +  1:NEXT(312$); 

311$  ASSIGN:  ACAT  I  Acquisition  Planning  PreB.Numberln=ACAT  I  Acquisition  Planning 

PreB.Numberln  +  1: 

ACAT  I  Acquisition  Planning  PreB.WIP=ACAT  I  Acquisition  Planning  PreB.WIP+1; 

8749$  DELAY:  Triangular(120,240,250)„VA; 

8796$  ASSIGN:  ACAT  I  Acquisition  Planning  PreB.NumberOut=ACAT  I  Acquisition  Planning 

PreB.NumberOut  +  1: 

ACAT  I  Acquisition  Planning  PreB.WIP=ACAT  I  Acquisition  Planning  PreB.WIP- 

1:NEXT(8743$); 

312$  ASSIGN:  ACAT  II  Or  III  Acquisition  Planning  PreB.Numberln= 

ACAT  II  Or  III  Acquisition  Planning  PreB.Numberln  +  1: 

ACAT  II  Or  III  Acquisition  Planning  PreB.WIP=ACAT  II  Or  III  Acquisition  Planning 

PreB.WIP+1; 

8800$  DELAY:  Triangular(120,185,250)„VA; 

8847$  ASSIGN:  ACAT  II  Or  III  Acquisition  Planning  PreB.NumberOut= 

ACAT  II  Or  III  Acquisition  Planning  PreB.NumberOut  +  1: 

ACAT  II  Or  III  Acquisition  Planning  PreB.WIP=ACAT  II  Or  III  Acquisition  Planning 

PreB.WIP-1 

:NEXT(8743$); 

8743$  ASSIGN:  Acquisition  Planning  Activities  PreB.NumberOut=Acquisition  Planning  Activities 

PreB.NumberOut  +  1: 

Acquisition  Planning  Activities  PreB.WIP=Acquisition  Planning  Activities  PreB.WIP- 

1:NEXT(269$); 
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Model  statements  for  module:  BasicProcess. Batch  7  (Processes  come  together  PreB) 


269$  QUEUE,  Processes  come  together  PreB. Queue; 
8850$  GROUP,  , Permanent^, Last:NEXT(8851$); 


8851$  ASSIGN:  Processes  come  together  PreB.NumberOut=Processes  come  together 

PreB.NumberOut  +  1:NEXT(270$); 


;  Model  statements  for  module:  BasicProcess. Process  140  (Draft  RFP  Preparation  preB) 

/ 

270$  ASSIGN:  Draft  RFP  Preparation  preB.Numberln=Draft  RFP  Preparation  preB.Numberln  +  1: 

Draft  RFP  Preparation  preB.WIP=Draft  RFP  Preparation  preB.WIP+1; 

8853$  DELAY:  Triangular(10,17,20)„VA; 

8900$  ASSIGN:  Draft  RFP  Preparation  preB.NumberOut=Draft  RFP  Preparation  preB.NumberOut 

+  1: 

Draft  RFP  Preparation  preB.WIP=Draft  RFP  Preparation  preB.WIP-l:NEXT(271$); 


;  Model  statements  for  module:  BasicProcess. Separate  9  (Separate  activities  once  preB) 

/ 

271$  DUPLICATE,  100-0: 

1,8905$,0:NEXT(8904$); 

8904$  ASSIGN:  Separate  activities  once  preB.NumberOut  Orig=Separate  activities  once 

preB.NumberOut  Orig  +  1 

:NEXT(272$); 

8905$  ASSIGN:  Separate  activities  once  preB.NumberOut  Dup=Separate  activities  once 

preB.NumberOut  Dup  +  1 

:NEXT(273$); 


Model  statements  for  module:  BasicProcess. Process  141  (RFP  Coordination  Process  PreB) 
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272$  ASSIGN:  RFP  Coordination  Process  PreB.Numberln=RFP  Coordination  Process 

PreB.Numberln  +  1: 

RFP  Coordination  Process  PreB.WIP=RFP  Coordination  Process  PreB.WIP+1; 

8907$  DELAY:  Triangular(25,45,50)„VA; 

8954$  ASSIGN:  RFP  Coordination  Process  PreB.NumberOut=RFP  Coordination  Process 

PreB.NumberOut  +  1: 

RFP  Coordination  Process  PreB.WIP=RFP  Coordination  Process  PreB.WIP-l:NEXT(341$); 


;  Model  statements  for  module:  BasicProcess. Process  142  (Source  selection  plans  preB) 

/ 

273$  ASSIGN:  Source  selection  plans  preB.Numberln=Source  selection  plans  preB.Numberln  + 

1: 

Source  selection  plans  preB.WIP=Source  selection  plans  preB.WIP+1; 

8958$  DELAY:  Triangular(30,60,65)„VA; 

9005$  ASSIGN:  Source  selection  plans  preB.NumberOut=Source  selection  plans 

preB.NumberOut  +  1: 

Source  selection  plans  preB.WIP=Source  selection  plans  preB.WIP-l:NEXT(341$); 


;  Model  statements  for  module:  BasicProcess. Process  160  (Contract  Startup  PreB) 

/ 

313$  ASSIGN:  Contract  Startup  PreB.Numberln=Contract  Startup  PreB.Numberln  +  1: 

Contract  Startup  PreB.WIP=Contract  Startup  PreB.WIP+1; 

9009$  DELAY:  Triangular(30,42,45)„VA; 

9056$  ASSIGN:  Contract  Startup  PreB.NumberOut=Contract  Startup  PreB.NumberOut  +  1: 

Contract  Startup  PreB.WIP=Contract  Startup  PreB.WIP-l:NEXT(370$); 


;  Model  statements  for  module:  BasicProcess. Assign  70  (Set  Contract  Start  variable) 
/ 

370$  ASSIGN:  contract  start=l:NEXT(361$); 
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;  Model  statements  for  module:  AdvancedProcess.Hold  5  (Wait  for  T  and  E  Start) 

/ 

361$  QUEUE,  Wait  for  T  and  E  Start. Queue; 

SCAN:  T  and  E  Start  PreB==l  &&  KPP  Development  signal  PreB  ==  1:NEXT(323$); 


;  Model  statements  for  module:  BasicProcess. Process  163  (Developmental  Test  and  Evaluation) 

/ 

323$  ASSIGN:  Developmental  Test  and  Evaluation. Numberln=Developmental  Test  and 

Evaluation. Numberln  +  1: 

Developmental  Test  and  Evaluation. WIP=Developmental  Test  and 
Evaluation.  WIP+1:NEXT(324$); 

324$  BRANCH,  1: 

lf,ACAT  Level==l, 9110$, Yes: 

Else, 9111$, Yes; 

9110$  ASSIGN:  Dev  testing  activities  depend  upon  ACAT  level  preB.NumberOut  True= 

Dev  testing  activities  depend  upon  ACAT  level  preB.NumberOut  True  +  1:NEXT(327$); 

9111$  ASSIGN:  Dev  testing  activities  depend  upon  ACAT  level  preB.NumberOut  False= 

Dev  testing  activities  depend  upon  ACAT  level  preB.NumberOut  False  +  1:NEXT(328$); 

327$  ASSIGN:  testinglength=TD  Contract  length*0.25:NEXT(325$); 

325$  ASSIGN:  ACAT  I  Dev  testing  PreB.Numberln=ACAT  I  Dev  testing  PreB. Numberln  +  1: 

ACAT  I  Dev  testing  PreB.WIP=ACAT  I  Dev  testing  PreB.WIP+1; 

9113$  DELAY:  TRIA(  ,75*testinglength  ,  testinglength  ,  l.l*testinglength  )„VA; 

9160$  ASSIGN:  ACAT  I  Dev  testing  PreB.NumberOut=ACAT  I  Dev  testing  PreB.NumberOut  +  1: 

ACAT  I  Dev  testing  PreB.WIP=ACAT  I  Dev  testing  PreB.WIP-l:NEXT(9107$); 

328$  ASSIGN:  testinglength=TD  Contract  length  *  0.15:NEXT(326$); 

326$  ASSIGN:  ACAT  II  Or  III  Dev  testing  PreB.Numberln=ACAT  II  Or  III  Dev  testing 

PreB. Numberln  +  1: 

ACAT  II  Or  III  Dev  testing  PreB.WIP=ACAT  II  Or  III  Dev  testing  PreB.WIP+1; 

9164$  DELAY:  TRIA(  ,75*testinglength  ,  testinglength  ,  l.l*testinglength  )„VA; 

9211$  ASSIGN:  ACAT  II  Or  III  Dev  testing  PreB.NumberOut=ACAT  II  Or  III  Dev  testing 

PreB.NumberOut  +  1: 

ACAT  II  Or  III  Dev  testing  PreB.WIP=ACAT  II  Or  III  Dev  testing  PreB.WIP-l:NEXT(9107$); 
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9107$  ASSIGN:  Developmental  Test  and  Evaluation. NumberOut=Developmental  Test  and 

Evaluation.  NumberOut  +  1: 

Developmental  Test  and  Evaluation. WIP=Developmental  Test  and  Evaluation. WIP- 

1:NEXT(329$); 


;  Model  statements  for  module:  BasicProcess. Decide  140  (Trades  Needed) 

/ 

329$  BRANCH,  1: 

With, (70)/100, 9214$, Yes: 

Else, 9215$, Yes; 

9214$  ASSIGN:  Trades  Needed. NumberOut  True=Trades  Needed. NumberOut  True  + 

1:NEXT(333$); 

9215$  ASSIGN:  Trades  Needed. NumberOut  False=Trades  Needed. NumberOut  False  + 

1:NEXT(330$); 


;  Model  statements  for  module:  BasicProcess. Process  167  (Dev  testing  rework  and  delay) 

/ 

333$  ASSIGN:  Dev  testing  rework  and  delay. Numberln=Dev  testing  rework  and  delay. Numberln 

+  1: 

Dev  testing  rework  and  delay. WIP=Dev  testing  rework  and  delay. WIP+1; 

9217$  DELAY:  Triangular(30,90,180)„VA; 

9264$  ASSIGN:  Dev  testing  rework  and  delay. NumberOut=Dev  testing  rework  and 

delay. NumberOut  +  1: 

Dev  testing  rework  and  delay. WIP=Dev  testing  rework  and  delay. WIP-1:NEXT(330$); 


;  Model  statements  for  module:  BasicProcess. Process  166  (Early  Operational  Assessment) 

/ 

330$  ASSIGN:  Early  Operational  Assessment. Numberln=Early  Operational 

Assessment. Numberln  +  1: 

Early  Operational  Assessment. WIP=Early  Operational  Assessment. WIP+1:NEXT(332$); 
332$  ASSIGN:  TD  Contract  End  Date  Near=l: 
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testinglength=TD  Contract  length*.  10:NEXT(331$); 


331$  ASSIGN:  EOA  PreB.Numberln=EOA  PreB.Numberln  +  1: 

EOA  PreB.WIP=EOA  PreB.WIP+1; 

9319$  DELAY:  TRIA(  ,75*testinglength  ,  testinglength  ,  l.l*testinglength  )„VA; 

9366$  ASSIGN:  EOA  PreB.NumberOut=EOA  PreB.NumberOut  +  1: 

EOA  PreB.WIP=EOA  PreB.WIP-l:NEXT(9315$); 

9315$  ASSIGN:  Early  Operational  Assessment. NumberOut=Early  Operational 

Assessment. NumberOut  +  1: 

Early  Operational  Assessment. WIP=Early  Operational  Assessment. WIP-1:NEXT(377$); 


;  Model  statements  for  module:  BasicProcess. Assign  72  (Declare  EOA  success) 
/ 

377$  ASSIGN:  EOA  success=l:NEXT(334$); 


;  Model  statements  for  module:  BasicProcess. Decide  142  (Additional  Adjustments) 

/ 

334$  BRANCH,  1: 

With, (50)/100, 9369$, Yes: 

Else, 9370$, Yes; 

9369$  ASSIGN:  Additional  Adjustments. NumberOut  True=Additional  Adjustments. NumberOut 

True  +  1:NEXT(335$); 

9370$  ASSIGN:  Additional  Adjustments. NumberOut  False=Additional  Adjustments. NumberOut 

False  +  1:NEXT(336$); 


;  Model  statements  for  module:  BasicProcess. Process  170  (EOA  rework  and  delay  preB) 

/ 

335$  ASSIGN:  EOA  rework  and  delay  preB.Numberln=EOA  rework  and  delay  preB.Numberln  + 

1: 

EOA  rework  and  delay  preB.WIP=EOA  rework  and  delay  preB.WIP+1; 

9372$  DELAY:  Triangular(30,90,180)„VA; 
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9419$  ASSIGN:  EOA  rework  and  delay  preB.NumberOut=EOA  rework  and  delay 

preB.NumberOut  +  1: 

EOA  rework  and  delay  preB.WIP=EOA  rework  and  delay  preB.WIP-l:NEXT(336$); 


;  Model  statements  for  module:  BasicProcess. Decide  143  (System  Requirements  Review) 

/ 

336$  BRANCH,  1: 

With, (35)/100, 9422$, Yes: 

Else, 9423$, Yes; 

9422$  ASSIGN:  System  Requirements  Review. NumberOut  True=System  Requirements 

Review. NumberOut  True  +  1:NEXT(340$); 

9423$  ASSIGN:  System  Requirements  Review. NumberOut  False=System  Requirements 

Review. NumberOut  False  +  1 
:NEXT(337$); 


;  Model  statements  for  module:  BasicProcess. Assign  54  (System  Performance  Specification  delivery) 
/ 

340$  ASSIGN:  End  TD  contract=l: 

TD  final  contract  length=TD  Contract  length: 

System  Performance  Specification=TNOW:NEXT(269$); 


;  Model  statements  for  module:  BasicProcess. Process  171  (SRR  rework  and  delay) 

/ 

337$  ASSIGN:  SRR  rework  and  delay. Numberln=SRR  rework  and  delay. Numberln  +  1: 

SRR  rework  and  delay. WIP=SRR  rework  and  delay. WIP+1; 

9425$  DELAY:  Triangular(60,160,180)„VA; 

9472$  ASSIGN:  SRR  rework  and  delay. NumberOut=SRR  rework  and  delay. NumberOut  +  1: 

SRR  rework  and  delay. WIP=SRR  rework  and  delay. WIP-1:NEXT(340$); 
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;  Model  statements  for  module:  BasicProcess. Assign  39  (ACAT  I  Contract  Length) 
/ 

289$  ASSIGN:  TD  Contract  Start=TNOW: 

contract  cost=l: 

TD  original  contract  length=TRIA(365,  1980,  2190):NEXT(371$); 


;  Model  statements  for  module:  BasicProcess. Assign  40  (ACAT  II  Contract  Length) 
/ 

290$  ASSIGN:  contract  cost=l: 

TD  Contract  Start=TNOW: 

TD  original  contract  length=TRIA(365,1365,2190):NEXT(371$); 


;  Model  statements  for  module:  BasicProcess. Decide  62  (Check  for  previous  MDA  decision  attempt 
preA) 

/ 

168$  BRANCH,  1: 

If, MS  A  approval  attempt==l, 9475$, Yes: 

Else, 9476$, Yes; 

9475$  ASSIGN:  Check  for  previous  MDA  decision  attempt  preA.NumberOut  True= 

Check  for  previous  MDA  decision  attempt  preA.NumberOut  True  +  1:NEXT(358$); 

9476$  ASSIGN:  Check  for  previous  MDA  decision  attempt  preA.NumberOut  False= 

Check  for  previous  MDA  decision  attempt  preA.NumberOut  False  +  1:NEXT(170$); 


;  Model  statements  for  module:  BasicProcess. Assign  61  (End  simulation  6) 
/ 

358$  ASSIGN:  Kill  at  MS  A  decision  time=TNOW: 

TFIN=TNOW:NEXT(663$); 


Model  statements  for  module:  BasicProcess. Record  7  (Record  7) 
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663$  TALLY: 


Record  7,INT(SimTime),l:NEXT(169$); 


;  Model  statements  for  module:  BasicProcess. Dispose  15  (Kill  at  MS  A  decision) 

/ 

169$  ASSIGN:  Kill  at  MS  A  decision. NumberOut=Kill  at  MS  A  decision. NumberOut  +  1; 

9477$  DISPOSE:  No; 


;  Model  statements  for  module:  BasicProcess. Assign  21  (Assign  counter  to  MDA  loop) 
/ 

170$  ASSIGN:  MS  A  approval  attempt=l:NEXT(158$); 


;  Model  statements  for  module:  BasicProcess. Separate  5  (Separate  again  preA) 

/ 

159$  DUPLICATE,  100-0: 

1,9480$,0:NEXT(9479$); 

9479$  ASSIGN:  Separate  again  preA. NumberOut  Orig=Separate  again  preA. NumberOut  Orig  + 

1:NEXT(163$); 

9480$  ASSIGN:  Separate  again  preA. NumberOut  Dup=Separate  again  preA. NumberOut  Dup  + 

1:NEXT(161$); 


;  Model  statements  for  module:  BasicProcess. Decide  60  (ACAT  level  check  preA) 

/ 

163$  BRANCH,  1: 

If, ACAT  Level==l, 9481$, Yes: 

Else, 9482$, Yes; 

9481$  ASSIGN:  ACAT  level  check  preA. NumberOut  True=ACAT  level  check  preA. NumberOut 

True  +  1:NEXT(162$); 
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9482$  ASSIGN:  ACAT  level  check  preA.NumberOut  False=ACAT  level  check  preA.NumberOut 

False  +  1:NEXT(164$); 


;  Model  statements  for  module:  BasicProcess. Process  76  (ACAT  1  Preparation  for  Acquisition  Panels 
preA) 

/ 

162$  ASSIGN:  ACAT  1  Preparation  for  Acquisition  Panels  preA.Numberln= 

ACAT  1  Preparation  for  Acquisition  Panels  preA.Numberln  +  1: 

ACAT  1  Preparation  for  Acquisition  Panels  preA.WIP= 

ACAT  1  Preparation  for  Acquisition  Panels  preA.WIP+1; 

9484$  DELAY:  Triangular(40,56,60)„VA; 

9531$  ASSIGN:  ACAT  1  Preparation  for  Acquisition  Panels  preA.NumberOut= 

ACAT  1  Preparation  for  Acquisition  Panels  preA.NumberOut  +  1: 

ACAT  1  Preparation  for  Acquisition  Panels  preA.WIP= 

ACAT  1  Preparation  for  Acquisition  Panels  preA.WIP-l:NEXT(136$); 


;  Model  statements  for  module:  BasicProcess. Decide  55  (Funds  Available  preA) 

/ 

136$  BRANCH,  1: 

With, (75)/100, 9534$, Yes: 

Else, 9535$, Yes; 

9534$  ASSIGN:  Funds  Available  preA.NumberOut  True=Funds  Available  preA.NumberOut  True  + 

1:NEXT(165$); 

9535$  ASSIGN:  Funds  Available  preA.NumberOut  False=Funds  Available  preA.NumberOut  False 

+  1:NEXT(139$); 


;  Model  statements  for  module:  BasicProcess. Decide  56  (ACAT  level  preA) 
/ 

139$  BRANCH,  1: 

If, ACAT  Level==l, 9536$, Yes: 

Else, 9537$, Yes; 


481 


9536$  ASSIGN:  AC  AT  level  preA.NumberOut  True=ACAT  level  preA.NumberOut  True  + 

1:NEXT(137$); 

9537$  ASSIGN:  ACAT  level  preA.NumberOut  False=ACAT  level  preA.NumberOut  False  + 

1:NEXT(138$); 


;  Model  statements  for  module:  BasicProcess. Process  66  (ACAT  I  time  delay) 

/ 

137$  ASSIGN:  ACAT  I  time  delay. Numberln=ACAT  I  time  delay. Numberln  +  1: 

ACAT  I  time  delay.WIP=ACAT  I  time  delay.WIP+1; 

9539$  DELAY:  Triangular(30,45,180)„VA; 

9586$  ASSIGN:  ACAT  I  time  delay. NumberOut=ACAT  I  time  delay.NumberOut  +  1: 

ACAT  I  time  delay.WIP=ACAT  I  time  delay.WIP-l:NEXT(165$); 


;  Model  statements  for  module:  BasicProcess. Process  67  (ACAT  II  or  ACAT  III  time  delay) 

/ 

138$  ASSIGN:  ACAT  II  or  ACAT  III  time  delay. Numberln=ACAT  II  or  ACAT  III  time  delay. Numberln 

+  1: 

ACAT  II  or  ACAT  III  time  delay.WIP=ACAT  II  or  ACAT  III  time  delay.WIP+1; 

9590$  DELAY:  Triangular(90,150,240)„VA; 

9637$  ASSIGN:  ACAT  II  or  ACAT  III  time  delay.NumberOut=ACAT  II  or  ACAT  III  time 

delay.NumberOut  +  1: 

ACAT  II  or  ACAT  III  time  delay.WIP=ACAT  II  or  ACAT  III  time  delay.WIP-l:NEXT(165$); 


;  Model  statements  for  module:  BasicProcess. Process  77  (ACAT  II  or  III  Preparation  for  Acquisition 
Panels) 

/ 

164$  ASSIGN:  ACAT  II  or  III  Preparation  for  Acquisition  Panels. Numberln= 

ACAT  II  or  III  Preparation  for  Acquisition  Panels. Numberln  +  1: 

ACAT  II  or  III  Preparation  for  Acquisition  Panels. WIP= 

ACAT  II  or  III  Preparation  for  Acquisition  Panels. WIP+1; 

9641$  DELAY:  Triangular(15,25,30)„VA; 

9688$  ASSIGN:  ACAT  II  or  III  Preparation  for  Acquisition  Panels. NumberOut= 
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ACAT  II  or  III  Preparation  for  Acquisition  Panels. NumberOut  +  1: 
ACAT  II  or  III  Preparation  for  Acquisition  Panels. WIP= 

ACAT  II  or  III  Preparation  for  Acquisition  Panels. WIP-1:NEXT(136$); 


;  Model  statements  for  module:  BasicProcess. Process  75  (Source  selection  plans  preA) 

/ 

161$  ASSIGN:  Source  selection  plans  preA.Numberln=Source  selection  plans  preA.Numberln  + 

1: 

Source  selection  plans  preA.WIP=Source  selection  plans  preA.WIP+1; 

9692$  DELAY:  Triangular(30,60,65)„VA; 

9739$  ASSIGN:  Source  selection  plans  preA.NumberOut=Source  selection  plans 

preA.NumberOut  +  1: 

Source  selection  plans  preA.WIP=Source  selection  plans  preA.WIP-l:NEXT(165$); 


;  Model  statements  for  module:  BasicProcess. Assign  16  (Kill  program  at  selected  COA) 
/ 

134$  ASSIGN:  Selected  CoA  Kill  point=l:NEXT(357$); 


;  Model  statements  for  module:  BasicProcess. Assign  60  (End  Simulation  5) 
/ 

357$  ASSIGN:  End  at  COA  PreA=TNOW: 

tfin=TNOW:NEXT(661$); 


;  Model  statements  for  module:  BasicProcess. Record  5  (Record  5) 
/ 

661$  TALLY:  Record  5,INT(SimTime),l:NEXT(135$); 
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Model  statements  for  module:  BasicProcess. Dispose  13  (End  Process  at  COA) 


135$  ASSIGN:  End  Process  at  COA.NumberOut=End  Process  at  COA.NumberOut  +  1; 

9742$  DISPOSE:  No; 


;  Model  statements  for  module:  BasicProcess. Separate  3  (Continute  other  Acquisition  Swimlane 
activities  preA) 

/ 

153$  DUPLICATE,  100-0: 

1,9745$,0:NEXT(9744$); 

9744$  ASSIGN:  Continute  other  Acquisition  Swimlane  activities  preA.NumberOut  Orig= 

Continute  other  Acquisition  Swimlane  activities  preA.NumberOut  Orig  +  1:NEXT(131$); 

9745$  ASSIGN:  Continute  other  Acquisition  Swimlane  activities  preA.NumberOut  Dup= 

Continute  other  Acquisition  Swimlane  activities  preA.NumberOut  Dup  +  1:NEXT(154$); 


;  Model  statements  for  module:  BasicProcess. Process  63  (Develop  Courses  of  Action) 

/ 

131$  ASSIGN:  Develop  Courses  of  Action. Numberln=Develop  Courses  of  Action. Numberln  +  1: 

Develop  Courses  of  Action. WIP=Develop  Courses  of  Action. WIP+1; 

9747$  DELAY:  Triangular(30,160,180)„VA; 

9794$  ASSIGN:  Develop  Courses  of  Action. NumberOut=Develop  Courses  of  Action. NumberOut  + 

1: 

Develop  Courses  of  Action. WIP=Develop  Courses  of  Action. WIP-1:NEXT(150$); 


;  Model  statements  for  module:  BasicProcess. Process  72  (Develop  TandE  strategy  and  Technology 
Development  Strategy) 

/ 

154$  ASSIGN:  Develop  TandE  strategy  and  Technology  Development  Strategy. Numberln= 

Develop  TandE  strategy  and  Technology  Development  Strategy. Numberln  +  1: 
Develop  TandE  strategy  and  Technology  Development  Strategy. WIP= 

Develop  TandE  strategy  and  Technology  Development  Strategy. WIP+1; 
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9798$  DELAY:  Triangular(30,150,180)„VA; 

9845$  ASSIGN:  Develop  TandE  strategy  and  Technology  Development  Strategy. NumberOut= 

Develop  TandE  strategy  and  Technology  Development  Strategy. NumberOut  +  1: 
Develop  TandE  strategy  and  Technology  Development  Strategy. WIP= 

Develop  TandE  strategy  and  Technology  Development  Strategy. WIP-1:NEXT(156$); 


;  Model  statements  for  module:  BasicProcess. Separate  2  (Trigger  Acquisition  swimlane  activity) 
/ 

140$  DUPLICATE,  100-0: 

1,9850$,0:NEXT(9849$); 

9849$  ASSIGN:  Trigger  Acquisition  swimlane  activity. NumberOut  Orig= 

Trigger  Acquisition  swimlane  activity. NumberOut  Orig  +  1:NEXT(127$); 

9850$  ASSIGN:  Trigger  Acquisition  swimlane  activity. NumberOut  Dup= 

Trigger  Acquisition  swimlane  activity. NumberOut  Dup  +  1:NEXT(653$); 


;  Model  statements  for  module:  BasicProcess. Decide  53  (Conduct  AoA) 

/ 

127$  BRANCH,  1: 

With, (99)/100, 9851$, Yes: 

Else, 9852$, Yes; 

9851$  ASSIGN:  Conduct  AoA.NumberOut  True=Conduct  AoA. NumberOut  True  +  1:NEXT(152$); 

9852$  ASSIGN:  Conduct  AoA.NumberOut  False=Conduct  AoA.NumberOut  False  +  1:NEXT(128$); 


;  Model  statements  for  module:  BasicProcess. Assign  19  (Start  time  check) 
/ 

152$  ASSIGN:  Start  AoA  flag=l: 

StarttimeofAoA=TNOW:NEXT(129$); 
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;  Model  statements  for  module:  BasicProcess. Process  61  (Analysis  of  Alternatives) 

/ 

129$  ASSIGN:  Analysis  of  Alternatives. Numberln=Analysis  of  Alternatives. Numberln  +  1: 

Analysis  of  Alternatives. WIP=Analysis  of  Alternatives.  WIP+1; 

9854$  DELAY:  Triangular(270,600,730)„VA; 

9901$  ASSIGN:  Analysis  of  Alternatives. NumberOut=Analysis  of  Alternatives. NumberOut  +  1: 

Analysis  of  Alternatives. WIP=Analysis  of  Alternatives. WIP-1:NEXT(151$); 


;  Model  statements  for  module:  BasicProcess. Assign  18  (End  Time  check) 
/ 

151$  ASSIGN:  CompletetimeofAoA=TNOW:NEXT(150$); 


;  Model  statements  for  module:  BasicProcess. Assign  15  (Set  AoA  kill  flag) 
/ 

128$  ASSIGN:  AoA  killed=l:NEXT(356$); 


;  Model  statements  for  module:  BasicProcess. Assign  59  (End  simulation  4) 
/ 

356$  ASSIGN:  Killed  at  AoA=TNOW: 

TFIN=TNOW:NEXT(660$); 


;  Model  statements  for  module:  BasicProcess. Record  4  (Record  4) 
/ 

660$  TALLY:  Record  4, INT(SimTime),l:NEXT(33$); 


Model  statements  for  module:  BasicProcess. Dispose  9  (End  at  AoA  check) 


486 


33$  ASSIGN:  End  at  AoA  check. NumberOut=End  at  AoA  check. NumberOut  +  1; 

9904$  DISPOSE:  No; 


;  Model  statements  for  module:  AdvancedProcess.Hold  21  (Wait  for  AoA  Start) 
/ 

653$  QUEUE,  Wait  for  AoA  Start. Queue; 

SCAN:  Start  AoA  flag  ==  1:NEXT(153$); 


;  Model  statements  for  module:  BasicProcess. Process  60  (Develop  AoA  Plan) 

/ 

126$  ASSIGN:  Develop  AoA  Plan. Numberln=Develop  AoA  Plan. Numberln  +  1: 

Develop  AoA  Plan.WIP=Develop  AoA  Plan.WIP+1; 

9906$  DELAY:  Triangular(60,75,90)„VA; 

9953$  ASSIGN:  Develop  AoA  Plan.NumberOut=Develop  AoA  Plan. NumberOut  +  1: 

Develop  AoA  Plan.WIP=Develop  AoA  Plan.WIP-l:NEXT(140$); 


;  Model  statements  for  module:  BasicProcess. Decide  59  (Check  for  previous  path) 

/ 

146$  BRANCH,  1: 

lf,AcqPanelTry==l,9956$,Yes: 

Else, 9957$, Yes; 

9956$  ASSIGN:  Check  for  previous  path. NumberOut  True=Check  for  previous  path. NumberOut 

True  +  1:NEXT(359$); 

9957$  ASSIGN:  Check  for  previous  path. NumberOut  False=Check  for  previous  path. NumberOut 

False  +  1:NEXT(148$); 


Model  statements  for  module:  BasicProcess. Assign  62  (End  simulation  7) 
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359$  ASSIGN:  Kill  by  MDA  at  Concept  Decision  PreA=TNOW: 

TFIN=TNOW:NEXT(662$); 


;  Model  statements  for  module:  BasicProcess. Record  6  (Record  6) 
/ 

662$  TALLY:  Record  6,INT(SimTime),l:NEXT(147$); 


;  Model  statements  for  module:  BasicProcess. Dispose  14  (Kill  by  MDA  at  Concept  Decision) 
/ 

147$  ASSIGN:  Kill  by  MDA  at  Concept  Decision. NumberOut=Kill  by  MDA  at  Concept 

Decision.  NumberOut  +  1; 

9958$  DISPOSE:  No; 


;  Model  statements  for  module:  BasicProcess. Assign  17  (Set  path  counter) 
/ 

148$  ASSIGN:  AcqPanelTry=l:NEXT(141$); 


;  Model  statements  for  module:  BasicProcess. Process  69  (ACAT  II  or  III  Prepare  for  Acquisition  Panels 
preA) 

/ 

143$  ASSIGN:  ACAT  II  or  III  Prepare  for  Acquisition  Panels  preA.Numberln= 

ACAT  II  or  III  Prepare  for  Acquisition  Panels  preA.Numberln  +  1: 

ACAT  II  or  III  Prepare  for  Acquisition  Panels  preA.WIP= 

ACAT  II  or  III  Prepare  for  Acquisition  Panels  preA.WIP+1; 

9960$  DELAY:  Triangular(15,30,35)„VA; 

10007$  ASSIGN:  ACAT  II  or  III  Prepare  for  Acquisition  Panels  preA.NumberOut= 

ACAT  II  or  III  Prepare  for  Acquisition  Panels  preA. NumberOut  +  1: 

ACAT  II  or  III  Prepare  for  Acquisition  Panels  preA.WIP= 

ACAT  II  or  III  Prepare  for  Acquisition  Panels  preA.WIP-l:NEXT(144$); 
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;  Model  statements  for  module:  BasicProcess. Process  59  (Wait  for  a  year) 

/ 

122$  ASSIGN:  Wait  for  a  year.Numberln=Wait  for  a  year.Numberln  +  1: 

Wait  for  a  year.WIP=Wait  for  a  year.WIP+1; 

10011$  DELAY:  Triangular(180,250,270)„VA; 

10058$  ASSIGN:  Wait  for  a  year.NumberOut=Wait  for  a  year.NumberOut  +  1: 

Wait  for  a  year.WIP=Wait  for  a  year.WIP-l:NEXT(141$); 


;  Model  statements  for  module:  BasicProcess. Decide  50  (ACAT  II  or  ACAT  III  funding) 

/ 

123$  BRANCH,  1: 

With, (99)/100, 10061$, Yes: 

Else, 10062$, Yes; 

10061$  ASSIGN:  ACAT  II  or  ACAT  III  funding. NumberOut  True=ACAT  II  or  ACAT  III 

funding. NumberOut  True  +  1 
:NEXT(141$); 

10062$  ASSIGN:  ACAT  II  or  ACAT  III  funding.NumberOut  False=ACAT  II  or  ACAT  III 

funding. NumberOut  False  +  1 
:NEXT(124$); 


;  Model  statements  for  module:  BasicProcess. Assign  14  (Set  AoA  Flag) 
/ 

124$  ASSIGN:  AoA  flag=l:NEXT(122$); 


;  Model  statements  for  module:  BasicProcess. Record  37  (Record  37) 
/ 

678$  TALLY:  Record  37,INT(SimTime),l:NEXT(638$); 


489 


Model  statements  for  module:  BasicProcess. Assign  134  (Reinsert  into  Acquisition  Process  B) 


638$  ASSIGN:  Back  into  process  at  B  time=TNOW: 

Back  into  process  at  PreB=l:NEXT(157$); 

/ 

/ 

;  Model  statements  for  module:  BasicProcess. Record  38  (Record  38) 

/ 

679$  TALLY:  Record  38, INT(SimTime),l:NEXT(637$); 

/ 

/ 

;  Model  statements  for  module:  BasicProcess. Assign  133  (Reinsert  into  Acquisition  Process  C) 

/ 

637$  ASSIGN:  Back  into  process  at  C  time=TNOW: 

Back  into  process  at  PreC=l:NEXT(387$); 

/ 

/ 

;  Model  statements  for  module:  BasicProcess. Assign  57  (End  simulation  2) 

/ 

355$  ASSIGN:  Finish  in  Sustainment=TNOW: 

TFIN=TNOW:NEXT(658$); 

/ 

/ 

;  Model  statements  for  module:  BasicProcess. Record  2  (Record  2) 

/ 

658$  TALLY:  Record  2,INT(SimTime),l:NEXT(12$); 

/ 

/ 

;  Model  statements  for  module:  BasicProcess. Dispose  2  (Continue  until  completion  and  End  of 
process) 
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12$  ASSIGN:  Continue  until  completion  and  End  of  process. NumberOut= 

Continue  until  completion  and  End  of  process. NumberOut  +  1; 
10063$  DISPOSE:  No; 


;  Model  statements  for  module:  BasicProcess. Process  5  (Determine  type  of  requirements  document 
needed) 

/ 

8$  ASSIGN:  Determine  type  of  requirements  document  needed. Numberln= 

Determine  type  of  requirements  document  needed. Numberln  +  1: 

Determine  type  of  requirements  document  needed. WIP= 

Determine  type  of  requirements  document  needed. WIP+1; 

10065$  DELAY:  Triangular(14,118,180)„VA; 

10112$  ASSIGN:  Determine  type  of  requirements  document  needed. NumberOut= 

Determine  type  of  requirements  document  needed. NumberOut  +  1: 

Determine  type  of  requirements  document  needed. WIP= 

Determine  type  of  requirements  document  needed. WIP-1:NEXT(9$); 


;  Model  statements  for  module:  BasicProcess. Decide  5  (Which  Milestone?) 
/ 

9$  BRANCH,  1: 

With, (35)/100, 641$, Yes: 

With, (60)/100, 643$, Yes: 

Else, 642$, Yes; 


;  Model  statements  for  module:  BasicProcess. Assign  138  (Requires  AoA  not  ICD) 
/ 

642$  ASSIGN:  Needs  AOA  ICD  OK=l: 

Requires  AoA  but  not  ICD=TNOW:NEXT(680$); 


Model  statements  for  module:  BasicProcess. Record  39  (Record  39) 
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680$  TALLY: 


Record  39,INT(SimTime),l:NEXT(120$); 


;  Model  statements  for  module:  BasicProcess. Assign  137  (In  Scope  of  existing  CCD) 
/ 

641$  ASSIGN:  PreB  CCD  OK=l: 

Scope  of  Existing  CCD=TNOW:NEXT(681$); 

/ 

/ 

;  Model  statements  for  module:  BasicProcess. Record  40  (Record  40) 

/ 

681$  TALLY:  Record  40, INT(SimTime),l:NEXT(279$); 

/ 

/ 

;  Model  statements  for  module:  BasicProcess. Assign  139  (Entry  after  MS  B) 

/ 

643$  ASSIGN:  Direct  entry  to  PreC  Phase=l: 

Direct  entry  into  SDD  phase=TNOW:NEXT(682$); 

/ 

/ 

;  Model  statements  for  module:  BasicProcess. Record  41  (Record  41) 

/ 

682$  TALLY:  Record  41, INT(SimTime),l:NEXT(387$); 

/ 

/ 

;  Model  statements  for  module:  BasicProcess. Process  9  (Waiting  Period) 

/ 

13$  ASSIGN:  Waiting  Period. Numberln=Waiting  Period. Numberln  +  1: 

Waiting  Period. WIP=Waiting  Period. WIP+1; 

10118$  DELAY:  Triangular(14,118,180)„VA; 

10165$  ASSIGN:  Waiting  Period. NumberOut=Waiting  Period. NumberOut  +  1: 
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Waiting  Period. WIP=Waiting  Period.WIP-l:NEXT(14$); 


;  Model  statements  for  module:  BasicProcess. Decide  8  (Decision  to  pursue  requirements) 

/ 

14$  BRANCH,  1: 

With, (25)/100, 10168$, Yes: 

Else, 10169$, Yes; 

10168$  ASSIGN:  Decision  to  pursue  requirements. NumberOut  True=Decision  to  pursue 

requirements. NumberOut  True  +  1 
:NEXT(17$); 

10169$  ASSIGN:  Decision  to  pursue  requirements. NumberOut  False=Decision  to  pursue 

requirements. NumberOut  False  +  1 
:NEXT(383$); 


;  Model  statements  for  module:  BasicProcess. Process  11  (Draft  briefing  and  materials) 

/ 

17$  ASSIGN:  Draft  briefing  and  materials. Numberln=Draft  briefing  and  materials. Numberln  +  1: 

Draft  briefing  and  materials. WIP=Draft  briefing  and  materials. WIP+1; 

10171$  DELAY:  Triangular(10,31,40)„VA; 

10218$  ASSIGN:  Draft  briefing  and  materials. NumberOut=Draft  briefing  and 

materials. NumberOut  +  1: 

Draft  briefing  and  materials. WIP=Draft  briefing  and  materials. WIP-1:NEXT(19$); 


;  Model  statements  for  module:  BasicProcess. Decide  9  (MAJCOM  A  Letters  Coordinate  and  Concur) 
/ 

19$  BRANCH,  1: 

With, (80)/100, 10221$, Yes: 

Else, 10222$, Yes; 

10221$  ASSIGN:  MAJCOM  A  Letters  Coordinate  and  Concur. NumberOut  True= 

MAJCOM  A  Letters  Coordinate  and  Concur. NumberOut  True  +  1:NEXT(43$); 

10222$  ASSIGN:  MAJCOM  A  Letters  Coordinate  and  Concur. NumberOut  False= 
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MAJCOM  A  Letters  Coordinate  and  Concur. NumberOut  False  +  1:NEXT(32$); 


;  Model  statements  for  module:  BasicProcess. Decide  21  (Check  for  ACAT  level  preA) 

/ 

43$  BRANCH,  1: 

If, ACAT  Level==l,  10223$, Yes: 

Else, 10224$, Yes; 

10223$  ASSIGN:  Check  for  ACAT  level  preA. NumberOut  True=Check  for  ACAT  level 

preA. NumberOut  True  +  1:NEXT(20$); 

10224$  ASSIGN:  Check  for  ACAT  level  preA. NumberOut  False=Check  for  ACAT  level 

preA.NumberOut  False  +  1:NEXT(22$); 


;  Model  statements  for  module:  BasicProcess. Decide  10  (Request  for  Funds  between  August  and 
December) 

/ 

20$  BRANCH,  1: 

With, (70)/100, 10225$, Yes: 

Else, 10226$, Yes; 

10225$  ASSIGN:  Request  for  Funds  between  August  and  December. NumberOut  True= 

Request  for  Funds  between  August  and  December. NumberOut  True  +  1:NEXT(22$); 

10226$  ASSIGN:  Request  for  Funds  between  August  and  December. NumberOut  False= 

Request  for  Funds  between  August  and  December. NumberOut  False  +  1:NEXT(21$); 


;  Model  statements  for  module:  BasicProcess. Process  13  (Study  for  ICD  Development) 

/ 

22$  ASSIGN:  Study  for  ICD  Development. Numberln=Study  for  ICD  Development. Numberln  +  1: 

Study  for  ICD  Development. WIP=Study  for  ICD  Development. WIP+1:NEXT(23$); 

23$  BRANCH,  1: 

If, ACAT  Level==l,  10278$, Yes: 

Else, 10279$, Yes; 
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10278$  ASSIGN:  Determine  path.NumberOut  True=Determine  path. NumberOut  True  + 

1:NEXT(24$); 

10279$  ASSIGN:  Determine  path.NumberOut  False=Determine  path.NumberOut  False  + 

1:NEXT(25$); 

24$  ASSIGN:  Longer  Study. Numberln=Longer  Study. Numberln  +  1: 

Longer  Study. WIP=Longer  Study. WIP+1; 

10281$  DELAY:  Triangular(180,300,360)„VA; 

10328$  ASSIGN:  Longer  Study. NumberOut=Longer  Study. NumberOut  +  1: 

Longer  Study.WIP=Longer  Study.WIP-l:NEXT(10275$); 

25$  ASSIGN:  Short  study. Numberln=Short  study. Numberln  +  1: 

Short  study. WIP=Short  study. WIP+1; 

10332$  DELAY:  Triangular(l,5,7)„VA; 

10379$  ASSIGN:  Short  study. NumberOut=Short  study. NumberOut  +  1: 

Short  study. WIP=Short  study.WIP-l:NEXT(10275$); 

10275$  ASSIGN:  Study  for  ICD  Development. NumberOut=Study  for  ICD 

Development. NumberOut  +  1: 

Study  for  ICD  Development. WIP=Study  for  ICD  Development. WIP-1:NEXT(26$); 


;  Model  statements  for  module:  BasicProcess. Process  14  (Update  and  Schedule  Calendar) 

/ 

26$  ASSIGN:  Update  and  Schedule  Calendar. Numberln=Update  and  Schedule 

Calendar. Numberln  +  1: 

Update  and  Schedule  Calendar. WIP=Update  and  Schedule  Calendar. WIP+1; 

10383$  DELAY:  Triangular(3,12,15)„NVA; 

10430$  ASSIGN:  Update  and  Schedule  Calendar. NumberOut=Update  and  Schedule 

Calendar. NumberOut  +  1: 

Update  and  Schedule  Calendar. WIP=Update  and  Schedule  Calendar. WIP-1:NEXT(27$); 


;  Model  statements  for  module:  BasicProcess. Decide  11  (PreRSR  MAJCOM  A8) 
/ 

27$  BRANCH,  1: 

With, (95)/100,10433$, Yes: 
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Else, 10434$, Yes; 

10433$  ASSIGN:  PreRSR  MAJCOM  A8.NumberOut  True=PreRSR  MAJCOM  A8.NumberOut  True  + 

1:NEXT(28$); 

10434$  ASSIGN:  PreRSR  MAJCOM  A8.NumberOut  False=PreRSR  MAJCOM  A8.NumberOut  False  + 

1:NEXT(32$); 


;  Model  statements  for  module:  BasicProcess. Process  15  (Finalize  RSR  and  calendar  items) 

/ 

28$  ASSIGN:  Finalize  RSR  and  calendar  items. Numberln=Finalize  RSR  and  calendar 

items. Numberln  +  1: 

Finalize  RSR  and  calendar  items. WIP=Finalize  RSR  and  calendar  items. WIP+1; 

10436$  DELAY:  Triangular(21,28,35)„NVA; 

10483$  ASSIGN:  Finalize  RSR  and  calendar  items. NumberOut=Finalize  RSR  and  calendar 

items. NumberOut  +  1: 

Finalize  RSR  and  calendar  items. WIP=Finalize  RSR  and  calendar  items. WIP-1:NEXT(29$); 


;  Model  statements  for  module:  BasicProcess. Decide  12  (RSR  HQ  USAF  A5R) 

t 

29$  BRANCH,  1: 

With, (98)/100, 10486$, Yes: 

Else,  10487$, Yes; 

10486$  ASSIGN:  RSR  HQ  USAF  A5R. NumberOut  True=RSR  HQ  USAF  A5R. NumberOut  True  + 

1:NEXT(44$); 

10487$  ASSIGN:  RSR  HQ  USAF  A5R. NumberOut  False=RSR  HQ  USAF  A5R. NumberOut  False  + 

1:NEXT(32$); 


;  Model  statements  for  module:  BasicProcess. Process  22  (Form  High  Performance  Team) 
/ 

44$  ASSIGN:  Form  High  Performance  Team. Numberln=Form  High  Performance 

Team. Numberln  +  1: 

Form  High  Performance  Team. WIP=Form  High  Performance  Team. WIP+1; 
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10489$  DELAY:  Triangular(30, 41,45),,  Wait; 

10536$  ASSIGN:  Form  High  Performance  Team. NumberOut=Form  High  Performance 

Team.NumberOut  +  1: 

Form  High  Performance  Team. WIP=Form  High  Performance  Team.WIP-l:NEXT(45$); 


;  Model  statements  for  module:  BasicProcess. Process  23  (High  Performance  Team  work  preA) 

/ 

45$  ASSIGN:  High  Performance  Team  work  preA.Numberln=High  Performance  Team  work 

preA.Numberln  +  1: 

High  Performance  Team  work  preA.WIP=High  Performance  Team  work  preA.WIP+1; 
10540$  DELAY:  Triangular(5,6,7)„VA; 

10587$  ASSIGN:  High  Performance  Team  work  preA.NumberOut=High  Performance  Team  work 

preA.NumberOut  +  1: 

High  Performance  Team  work  preA.WIP=High  Performance  Team  work  preA.WIP- 

1:NEXT(46$); 


;  Model  statements  for  module:  BasicProcess. Decide  22  (Determine  document  approval  path  preA) 
/ 

46$  BRANCH,  1: 

lf,ACAT  Level==3,103$,Yes: 
lf,ACAT  Level==2,77$,Yes: 

Else, 47$, Yes; 


;  Model  statements  for  module:  BasicProcess. Process  24  (Joint  Interest  preA) 

/ 

47$  ASSIGN:  Joint  Interest  preA.Numberln=Joint  Interest  preA.Numberln  +  1: 

Joint  Interest  preA.WIP=Joint  Interest  preA.WIP+l:NEXT(48$); 

48$  ASSIGN:  draft  document  preA  joint  interest. Numberln=draft  document  preA  joint 

interest. Numberln  +  1: 

draft  document  preA  joint  interest. WIP=draft  document  preA  joint  interest. WIP+1; 
10644$  DELAY:  Triangular(30,55,60)„VA; 

10691$  ASSIGN:  draft  document  preA  joint  interest. N urn berOut=d raft  document  preA  joint 

interest. NumberOut  +  1: 
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draft  document  preA  joint  interest. WIP=draft  document  preA  joint  interest. WIP- 

1:NEXT(49$); 

49$  ASSIGN:  Air  Staff  processes  joint  int  preA.Numberln=Air  Staff  processes  joint  int 

preA.Numberln  +  1: 

Air  Staff  processes  joint  int  preA.WIP=Air  Staff  processes  joint  int  preA.WIP+1; 

10695$  DELAY:  Triangular(21,25,42)„VA; 

10742$  ASSIGN:  Air  Staff  processes  joint  int  preA.NumberOut=Air  Staff  processes  joint  int 

preA.NumberOut  +  1: 

Air  Staff  processes  joint  int  preA.WIP=Air  Staff  processes  joint  int  preA.WIP- 

1:NEXT(50$); 

50$  BRANCH,  1: 

With, (95)/100, 10745$, Yes: 

Else, 10746$, Yes; 

10745$  ASSIGN:  Critical  Comments?  joint  int  preA.NumberOut  True= 

Critical  Comments?  joint  int  preA.NumberOut  True  +  1:NEXT(51$); 

10746$  ASSIGN:  Critical  Comments?  joint  int  preA.NumberOut  False= 

Critical  Comments?  joint  int  preA.NumberOut  False  +  1:NEXT(54$); 

51$  ASSIGN:  Comment  Resolution  joint  int  preA.Numberln=Comment  Resolution  joint  int 

preA.Numberln  +  1: 

Comment  Resolution  joint  int  preA.WIP=Comment  Resolution  joint  int  preA.WIP+1; 
10748$  DELAY:  Triangular(15,30,45)„VA; 

10795$  ASSIGN:  Comment  Resolution  joint  int  preA.NumberOut=Comment  Resolution  joint  int 

preA.NumberOut  +  1: 

Comment  Resolution  joint  int  preA.WIP=Comment  Resolution  joint  int  preA.WIP- 

1:NEXT(52$); 

52$  BRANCH,  1: 

With, (99)/100, 10798$, Yes: 

Else, 10799$, Yes; 

10798$  ASSIGN:  MAJCOM  Approval?  joint  int  preA.NumberOut  True=MAJCOM  Approval?  joint 

int  preA.NumberOut  True  +  1 
:NEXT(54$); 

10799$  ASSIGN:  MAJCOM  Approval?  joint  int  preA.NumberOut  False=MAJCOM  Approval?  joint 

int  preA.NumberOut  False  +  1 
:NEXT(53$); 
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54$  ASSIGN:  AFROC  Preparations  joint  int  preA.Numberln=AFROC  Preparations  joint  int 

preA.Numberln  +  1: 

AFROC  Preparations  joint  int  preA.WIP=AFROC  Preparations  joint  int  preA.WIP+1; 
10801$  DELAY:  Triangular(30,45,60)„VA; 

10848$  ASSIGN:  AFROC  Preparations  joint  int  preA.NumberOut=AFROC  Preparations  joint  int 

preA.NumberOut  +  1: 

AFROC  Preparations  joint  int  preA.WIP=AFROC  Preparations  joint  int  preA.WIP- 

1:NEXT(55$); 

55$  BRANCH,  1: 

With, (90)/100, 10851$, Yes: 

Else, 10852$, Yes; 

10851$  ASSIGN:  AFROC  Decision  joint  int  preA.NumberOut  True=AFROC  Decision  joint  int 

preA.NumberOut  True  +  1 
:NEXT(56$); 

10852$  ASSIGN:  AFROC  Decision  joint  int  preA.NumberOut  False=AFROC  Decision  joint  int 

preA.NumberOut  False  +  1 
:NEXT(60$); 

56$  BRANCH,  1: 

With, (25)/100, 10853$, Yes: 

Else, 10854$, Yes; 

10853$  ASSIGN:  Post  AFROC  actions  joint  int  preA.NumberOut  True= 

Post  AFROC  actions  joint  int  preA.NumberOut  True  +  1:NEXT(61$); 

10854$  ASSIGN:  Post  AFROC  actions  joint  int  preA.NumberOut  False= 

Post  AFROC  actions  joint  int  preA.NumberOut  False  +  1:NEXT(62$); 

61$  ASSIGN:  Post  AFROC  actions. Numberln=Post  AFROC  actions. Numberln  +  1: 

Post  AFROC  actions. WIP=Post  AFROC  actions. WIP+1; 

10856$  DELAY:  Triangular(l,ll,15)„VA; 

10903$  ASSIGN:  Post  AFROC  actions. NumberOut=Post  AFROC  actions. NumberOut  +  1: 

Post  AFROC  actions. WIP=Post  AFROC  actions.WIP-l:NEXT(62$); 

62$  BRANCH,  1: 

With, (50)/100, 10906$, Yes: 

Else, 10907$, Yes; 

10906$  ASSIGN:  Document  Review  Phase. NumberOut  True=Document  Review 

Phase. NumberOut  True  +  1:NEXT(63$); 
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10907$  ASSIGN:  Document  Review  Phase. NumberOut  False=Document  Review 

Phase. NumberOut  False  +  1:NEXT(67$); 

63$  ASSIGN:  Document  Reveiw  Phase  2  Flag  Level. Numberln=Document  Reveiw  Phase  2  Flag 

Level. Numberln  + 1: 

Document  Reveiw  Phase  2  Flag  Level. WIP=Document  Reveiw  Phase  2  Flag  Level. WIP+1; 
10909$  DELAY:  Triangular(21,38,42)„VA; 

10956$  ASSIGN:  Document  Reveiw  Phase  2  Flag  Level. NumberOut=Document  Reveiw  Phase  2 

Flag  Level. NumberOut  +  1: 

Document  Reveiw  Phase  2  Flag  Level. WIP=Document  Reveiw  Phase  2  Flag  Level. WIP- 

1:NEXT(64$); 

64$  ASSIGN:  Resolving  Flag  level  comments. Numberln=Resolving  Flag  level 

comments. Numberln  +  1: 

Resolving  Flag  level  comments. WIP=Resolving  Flag  level  comments. WIP+1; 

10960$  DELAY:  Triangular(15,27,30)„VA; 

11007$  ASSIGN:  Resolving  Flag  level  comments. NumberOut=Resolving  Flag  level 

comments. NumberOut  +  1: 

Resolving  Flag  level  comments. WIP=Resolving  Flag  level  comments. WIP-1:NEXT(65$); 

65$  BRANCH,  1: 

With, (99)/100, 11010$, Yes: 

Else, 11011$, Yes; 

11010$  ASSIGN:  MAJCOM  approval. NumberOut  True=MAJCOM  approval. NumberOut  True  + 

1:NEXT(67$); 

11011$  ASSIGN:  MAJCOM  approval. NumberOut  False=MAJCOM  approval. NumberOut  False  + 

1:NEXT(66$); 

67$  ASSIGN:  Functional  Capabilities  Board. Numberln=Functional  Capabilities  Board. Numberln 

+  1: 

Functional  Capabilities  Board. WIP=Functional  Capabilities  Board. WIP+1; 

11013$  DELAY:  Triangular(7,14,21)„VA; 

11060$  ASSIGN:  Functional  Capabilities  Board. NumberOut=Functional  Capabilities 

Board. NumberOut  +  1: 

Functional  Capabilities  Board. WIP=Functional  Capabilities  Board. WIP-1:NEXT(68$); 

68$  ASSIGN:  Joint  Capabilities  Board. Numberln=Joint  Capabilities  Board. Numberln  +  1: 

Joint  Capabilities  Board. WIP=Joint  Capabilities  Board. WIP+1; 

11064$  DELAY:  Triangular(7,14,21)„VA; 

11111$  ASSIGN:  Joint  Capabilities  Board. NumberOut=Joint  Capabilities  Board. NumberOut  +  1: 

Joint  Capabilities  Board. WIP=Joint  Capabilities  Board. WIP-1:NEXT(69$); 
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69$  BRANCH,  1: 

With, (15)/100, 11114$, Yes: 

Else, 11115$, Yes; 

11114$  ASSIGN:  JCB  issues. NumberOut  True=JCB  issues. NumberOut  True  +  1:NEXT(70$); 

11115$  ASSIGN:  JCB  issues. NumberOut  False=JCB  issues. NumberOut  False  +  1:NEXT(71$); 

70$  ASSIGN:  Resolve  JCB  issues. Numberln=Resolve  JCB  issues. Numberln  +  1: 

Resolve  JCB  issues. WIP=Resolve  JCB  issues. WIP+1; 

11117$  DELAY:  Triangular(10,15,20)„VA; 

11164$  ASSIGN:  Resolve  JCB  issues. NumberOut=Resolve  JCB  issues. NumberOut  +  1: 

Resolve  JCB  issues. WIP=Resolve  JCB  issues. WIP-1:NEXT(71$); 

71$  ASSIGN:  JROC  preparations. Numberln=JROC  preparations. Numberln  +  1: 

JROC  preparations. WIP=JROC  preparations. WIP+1; 

11168$  DELAY:  Triangular(14,25,30)„VA; 

11215$  ASSIGN:  JROC  preparations. NumberOut=JROC  preparations. NumberOut  +  1: 

JROC  preparations. WIP=JROC  preparations. WIP-1:NEXT(72$); 

72$  BRANCH,  1: 

With, (98)/100, 11218$, Yes: 

Else, 11219$, Yes; 

11218$  ASSIGN:  JROC. NumberOut  True=JROC.NumberOut  True  +  1:NEXT(10640$); 

11219$  ASSIGN:  JROC. NumberOut  False=JROC.NumberOut  False  +  1:NEXT(73$); 

73$  ASSIGN:  Resolve  JROC  issues. Numberln=Resolve  JROC  issues. Numberln  +  1: 

Resolve  JROC  issues. WIP=Resolve  JROC  issues. WIP+1; 

11221$  DELAY:  Triangular(42,51,60)„VA; 

11268$  ASSIGN:  Resolve  JROC  issues. NumberOut=Resolve  JROC  issues. NumberOut  +  1: 

Resolve  JROC  issues. WIP=Resolve  JROC  issues. WIP-1:NEXT(10640$); 

66$  ASSIGN:  Hold  for  a  year  later  in  process. Numberln=Hold  for  a  year  later  in 

process. Numberln  +  1: 

Hold  for  a  year  later  in  process. WIP=Hold  for  a  year  later  in  process. WIP+1; 

11272$  DELAY:  Triangular(270,300,365)„NVA; 

11319$  ASSIGN:  Hold  for  a  year  later  in  process. NumberOut=Hold  for  a  year  later  in 

process. NumberOut  +  1: 

Hold  for  a  year  later  in  process. WIP=Hold  for  a  year  later  in  process. WIP-1:NEXT(67$); 
60$  BRANCH,  1: 
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lf,AFROC  Count==l, 11322$, Yes: 

Else, 11323$, Yes; 

11322$  ASSIGN:  Check  for  previous  path  joint  int  preA.NumberOut  True= 

Check  for  previous  path  joint  int  preA.NumberOut  True  +  1:NEXT(74$); 

11323$  ASSIGN:  Check  for  previous  path  joint  int  preA.NumberOut  False= 

Check  for  previous  path  joint  int  preA.NumberOut  False  +  1:NEXT(59$); 

74$  ASSIGN:  Kill  at  AFROC  joint  interest  PreA=TNOW: 

TFIN=TNOW:NEXT(75$); 

75$  TALLY:  Record  18,INT(SimTime),l:NEXT(58$); 

58$  ASSIGN:  Death  at  AFROC  joint  int  preA.NumberOut=Death  at  AFROC  joint  int 

preA.NumberOut  +  1; 

11324$  DISPOSE:  Yes; 

59$  ASSIGN:  AFROC  Count=l:NEXT(57$); 

57$  BRANCH,  1: 

With, (99)/100, 11325$, Yes: 

Else, 11326$, Yes; 

11325$  ASSIGN:  Dead  activity  joint  int  preA.NumberOut  True=Dead  activity  joint  int 

preA.NumberOut  True  +  1 
:NEXT(74$); 


11326$  ASSIGN:  Dead  activity  joint  int  preA.NumberOut  False=Dead  activity  joint  int 

preA.NumberOut  False  +  1 
:NEXT(51$); 


53$  ASSIGN: 

Hold 

11328$  DELAY: 
11375$  ASSIGN: 

Hold 

10640$  ASSIGN: 

Joint 


Hold  for  a  year.Numberln=Hold  for  a  year.Numberln  +  1: 
for  a  year.WIP=Hold  for  a  year.WIP+1; 

Triangular(270,300,365)„NVA; 

Hold  for  a  year.NumberOut=Hold  for  a  year.NumberOut  +  1: 
for  a  year.WIP=Hold  for  a  year.WIP-l:NEXT(54$); 

Joint  Interest  preA.NumberOut=Joint  Interest  preA.NumberOut  +  1: 
Interest  preA.WIP=Joint  Interest  preA.WIP-l:NEXT(76$); 
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Model  statements  for  module:  BasicProcess. Assign  11  (Record  ICD  time) 


76$  ASSIGN:  ICD=1: 

ICD  Time=TNOW:NEXT(120$); 


;  Model  statements  for  module:  BasicProcess. Process  52  (Independent  document  preA) 

/ 

103$  ASSIGN:  Independent  document  preA.Numberln=lndependent  document  preA.Numberln 

+  1: 

Independent  document  preA.WIP=lndependent  document  preA.WIP+l:NEXT(104$); 

104$  ASSIGN:  Draft  document  indep  preA.Numberln=Draft  document  indep  preA.Numberln  + 

1: 

Draft  document  indep  preA.WIP=Draft  document  indep  preA.WIP+1; 

11430$  DELAY:  Triangular(30,55,60)„VA; 

11477$  ASSIGN:  Draft  document  indep  preA.NumberOut=Draft  document  indep 

preA.NumberOut  +  1: 

Draft  document  indep  preA.WIP=Draft  document  indep  preA.WIP-l:NEXT(105$); 

105$  ASSIGN:  Air  staff  process  indep  preA.Numberln=Air  staff  process  indep  preA.Numberln  + 

1: 

Air  staff  process  indep  preA.WIP=Air  staff  process  indep  preA.WIP+1; 

11481$  DELAY:  Triangular(21,29,42)„VA; 

11528$  ASSIGN:  Air  staff  process  indep  preA.NumberOut=Air  staff  process  indep 

preA.NumberOut  +  1: 

Air  staff  process  indep  preA.WIP=Air  staff  process  indep  preA.WIP-l:NEXT(106$); 

106$  BRANCH,  1: 

With, (95)/100, 11531$, Yes: 

Else, 11532$, Yes; 

11531$  ASSIGN:  Critical  comments  indep  preA.NumberOut  True=Critical  comments  indep 

preA.NumberOut  True  +  1 

:NEXT(107$); 

11532$  ASSIGN:  Critical  comments  indep  preA.NumberOut  False=Critical  comments  indep 

preA.NumberOut  False  +  1 

:NEXT(110$); 
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107$  ASSIGN:  comment  resolution  indep  preA.Numberln=comment  resolution  indep 

preA.Numberln  +  1: 

comment  resolution  indep  preA.WIP=comment  resolution  indep  preA.WIP+1; 
11534$  DELAY:  Triangular(15,30,45)„VA; 

11581$  ASSIGN:  comment  resolution  indep  preA.NumberOut=comment  resolution  indep 

preA.NumberOut  +  1: 

comment  resolution  indep  preA.WIP=comment  resolution  indep  preA.WIP- 

1:NEXT(108$); 

108$  BRANCH,  1: 

With, (99)/100, 11584$, Yes: 

Else, 11585$, Yes; 

11584$  ASSIGN:  MAJCOM  approval  indep  preA.NumberOut  True=MAJCOM  approval  indep 

preA.NumberOut  True  +  1:NEXT(110$); 

11585$  ASSIGN:  MAJCOM  approval  indep  preA.NumberOut  False=MAJCOM  approval  indep 

preA.NumberOut  False  +  1 

:NEXT(109$); 

110$  ASSIGN:  AFROC  Preparations  indep  preA.Numberln=AFROC  Preparations  indep 

preA.Numberln  +  1: 

AFROC  Preparations  indep  preA.WIP=AFROC  Preparations  indep  preA.WIP+1; 
11587$  DELAY:  Triangular(30,45,60)„VA; 

11634$  ASSIGN:  AFROC  Preparations  indep  preA.NumberOut=AFROC  Preparations  indep 

preA.NumberOut  +  1: 

AFROC  Preparations  indep  preA.WIP=AFROC  Preparations  indep  preA.WIP- 

1:NEXT(111$); 

111$  BRANCH,  1: 

With, (90)/100, 11637$, Yes: 

Else, 11638$, Yes; 

11637$  ASSIGN:  AFROC  decision  indep  preA.NumberOut  True=AFROC  decision  indep 

preA.NumberOut  True  +  1:NEXT(116$); 

11638$  ASSIGN:  AFROC  decision  indep  preA.NumberOut  False=AFROC  decision  indep 

preA.NumberOut  False  +  1:NEXT(115$); 

116$  BRANCH,  1: 

With, (25)/100, 11639$, Yes: 

Else, 11640$, Yes; 

11639$  ASSIGN:  Post  AFROC  actions  indep  preA.NumberOut  True=Post  AFROC  actions  indep 

preA.NumberOut  True  +  1 
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:NEXT(117$); 


11640$  ASSIGN:  Post  AFROC  actions  indep  preA.NumberOut  False=Post  AFROC  actions  indep 

preA.NumberOut  False  +  1 

:NEXT(11426$); 

117$  ASSIGN:  Accomplish  Post  AFROC  actions  indep  preA.Numberln= 

Accomplish  Post  AFROC  actions  indep  preA.Numberln  +  1: 

Accomplish  Post  AFROC  actions  indep  preA.WIP=Accomplish  Post  AFROC  actions  indep 

preA.WIP+1; 

11642$  DELAY:  Triangular(l,ll,15)„VA; 

11689$  ASSIGN:  Accomplish  Post  AFROC  actions  indep  preA.NumberOut= 

Accomplish  Post  AFROC  actions  indep  preA.NumberOut  +  1: 

Accomplish  Post  AFROC  actions  indep  preA.WIP=Accomplish  Post  AFROC  actions  indep 

preA.WIP-1 

:NEXT(11426$); 

115$  BRANCH,  1: 

If, AFROC  Count==l, 11692$, Yes: 

Else, 11693$, Yes; 

11692$  ASSIGN:  Check  for  previous  path  indep  preA.NumberOut  True= 

Check  for  previous  path  indep  preA.NumberOut  True  +  1:NEXT(118$); 

11693$  ASSIGN:  Check  for  previous  path  indep  preA.NumberOut  False= 

Check  for  previous  path  indep  preA.NumberOut  False  +  1:NEXT(114$); 

118$  ASSIGN:  Kill  time  at  AFROC  indep  PreA=TNOW: 

TFIN=TNOW:NEXT(119$); 

119$  TALLY:  Record  20, INT(SimTime),l:NEXT(113$); 

113$  ASSIGN:  Death  at  AFROC  indep  preA.NumberOut=Death  at  AFROC  indep  preA.NumberOut 

+  l; 

11694$  DISPOSE:  Yes; 

114$  ASSIGN:  AFROC  Count=l:NEXT(112$); 

112$  BRANCH,  1: 

With, (99)/100, 11695$, Yes: 

Else, 11696$, Yes; 

11695$  ASSIGN:  Dead  activity  indep  preA.NumberOut  True=Dead  activity  indep 

preA.NumberOut  True  +  1:NEXT(118$); 
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11696$  ASSIGN:  Dead  activity  indep  preA.NumberOut  False=Dead  activity  indep 

preA.NumberOut  False  +  1:NEXT(107$); 


109$  ASSIGN:  Hold  for  a  year  later  in  process  indep  preA.Numberln= 

Hold  for  a  year  later  in  process  indep  preA.Numberln  +  1: 

Hold  for  a  year  later  in  process  indep  preA.WIP=Hold  for  a  year  later  in  process  indep 

preA.WIP+1; 

11698$  DELAY:  Triangular(270,300,365)„NVA; 

11745$  ASSIGN:  Hold  for  a  year  later  in  process  indep  preA.NumberOut= 

Hold  for  a  year  later  in  process  indep  preA.NumberOut  +  1: 

Hold  for  a  year  later  in  process  indep  preA.WIP=Hold  for  a  year  later  in  process  indep 

preA.WIP-1 

:NEXT(110$); 

11426$  ASSIGN:  Independent  document  preA.NumberOut=lndependent  document 

preA.NumberOut  +  1: 

Independent  document  preA.WIP=lndependent  document  preA.WIP-l:NEXT(76$); 


;  Model  statements  for  module:  BasicProcess. Process  39  (Joint  Integration  PreA) 

/ 

77$  ASSIGN:  Joint  Integration  PreA.Numberln=Joint  Integration  PreA.Numberln  +  1: 

Joint  Integration  PreA.WIP=Joint  Integration  PreA.WIP+l:NEXT(78$); 

78$  ASSIGN:  Draft  document  joint  integ  preA.Numberln=Draft  document  joint  integ 

preA.Numberln  +  1: 

Draft  document  joint  integ  preA.WIP=Draft  document  joint  integ  preA.WIP+1; 

11800$  DELAY:  Triangular(30,55,60)„VA; 

11847$  ASSIGN:  Draft  document  joint  integ  preA.NumberOut=Draft  document  joint  integ 

preA.NumberOut  +  1: 

Draft  document  joint  integ  preA.WIP=Draft  document  joint  integ  preA.WIP-l:NEXT(79$); 

79$  ASSIGN:  Air  staff  process  joint  integ  preA.Numberln=Air  staff  process  joint  integ 

preA.Numberln  +  1: 

Air  staff  process  joint  integ  preA.WIP=Air  staff  process  joint  integ  preA.WIP+1; 

11851$  DELAY:  Triangular(21,29,42)„VA; 

11898$  ASSIGN:  Air  staff  process  joint  integ  preA.NumberOut=Air  staff  process  joint  integ 

preA.NumberOut  +  1: 


506 


Air  staff  process  joint  integ  preA.WIP=Air  staff  process  joint  integ  preA.WIP- 

1:NEXT(80$); 

80$  BRANCH,  1: 

With, (95)/100, 11901$, Yes: 

Else, 11902$, Yes; 

11901$  ASSIGN:  Critical  comments  joint  integ  preA.NumberOut  True= 

Critical  comments  joint  integ  preA.NumberOut  True  +  1:NEXT(81$); 

11902$  ASSIGN:  Critical  comments  joint  integ  preA.NumberOut  False= 

Critical  comments  joint  integ  preA.NumberOut  False  +  1:NEXT(83$); 

81$  ASSIGN:  comment  resolution  joint  integ  preA.Numberln=comment  resolution  joint  integ 

preA.Numberln  +  1: 

comment  resolution  joint  integ  preA.WIP=comment  resolution  joint  integ  preA.WIP+1; 
11904$  DELAY:  Triangular(15,30,45)„VA; 

11951$  ASSIGN:  comment  resolution  joint  integ  preA.NumberOut=comment  resolution  joint 

integ  preA.NumberOut  +  1: 

comment  resolution  joint  integ  preA.WIP=comment  resolution  joint  integ  preA.WIP- 

1:NEXT(82$); 

82$  BRANCH,  1: 

With, (99)/100, 11954$, Yes: 

Else, 11955$, Yes; 

11954$  ASSIGN:  MAJCOM  approval  joint  integ  preA.NumberOut  True=MAJCOM  approval  joint 

integ  preA.NumberOut  True  +  1 
:NEXT(83$); 

11955$  ASSIGN:  MAJCOM  approval  joint  integ  preA.NumberOut  False= 

MAJCOM  approval  joint  integ  preA.NumberOut  False  +  1:NEXT(89$); 

83$  BRANCH,  1: 

With, (50)/100, 11956$, Yes: 

Else, 11957$, Yes; 

11956$  ASSIGN:  Document  review  phase  joint  integ  preA.NumberOut  True= 

Document  review  phase  joint  integ  preA.NumberOut  True  +  1:NEXT(84$); 

11957$  ASSIGN:  Document  review  phase  joint  integ  preA.NumberOut  False= 

Document  review  phase  joint  integ  preA.NumberOut  False  +  1:NEXT(87$); 

84$  ASSIGN:  Document  review  phase  2  flag  level  joint  integ  preA.Numberln= 

Document  review  phase  2  flag  level  joint  integ  preA.Numberln  +  1: 
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Document  review  phase  2  flag  level  joint  integ  preA.WIP= 

Document  review  phase  2  flag  level  joint  integ  preA.WIP+1; 

11959$  DELAY:  Triangular(21,34,42)„VA; 

12006$  ASSIGN:  Document  review  phase  2  flag  level  joint  integ  preA.NumberOut= 

Document  review  phase  2  flag  level  joint  integ  preA.NumberOut  +  1: 

Document  review  phase  2  flag  level  joint  integ  preA.WIP= 

Document  review  phase  2  flag  level  joint  integ  preA.WIP-l:NEXT(85$); 

85$  ASSIGN:  Resolving  flag  level  comments  joint  integ  preA.Numberln= 

Resolving  flag  level  comments  joint  integ  preA.Numberln  +  1: 

Resolving  flag  level  comments  joint  integ  preA.WIP= 

Resolving  flag  level  comments  joint  integ  preA.WIP+1; 

12010$  DELAY:  Triangular(15,28,30)„VA; 

12057$  ASSIGN:  Resolving  flag  level  comments  joint  integ  preA.NumberOut= 

Resolving  flag  level  comments  joint  integ  preA.NumberOut  +  1: 

Resolving  flag  level  comments  joint  integ  preA.WIP= 

Resolving  flag  level  comments  joint  integ  preA.WIP-l:NEXT(86$); 

86$  BRANCH,  1: 

With, (99)/100, 12060$, Yes: 

Else, 12061$, Yes; 

12060$  ASSIGN:  MAJCOM  approval  later  on  joint  integ  preA.NumberOut  True= 

MAJCOM  approval  later  on  joint  integ  preA.NumberOut  True  +  1:NEXT(87$); 

12061$  ASSIGN:  MAJCOM  approval  later  on  joint  integ  preA.NumberOut  False= 

MAJCOM  approval  later  on  joint  integ  preA.NumberOut  False  +  1:NEXT(90$); 

87$  ASSIGN:  Interoperability  Certification  joint  integ  preA.Numberln= 

Interoperability  Certification  joint  integ  preA.Numberln  +  1: 

Interoperability  Certification  joint  integ  preA.WIP= 

Interoperability  Certification  joint  integ  preA.WIP+1; 

12063$  DELAY:  Triangular(10,15,20)„VA; 

12110$  ASSIGN:  Interoperability  Certification  joint  integ  preA.NumberOut= 

Interoperability  Certification  joint  integ  preA.NumberOut  +  1: 

Interoperability  Certification  joint  integ  preA.WIP= 

Interoperability  Certification  joint  integ  preA.WIP-l:NEXT(88$); 

88$  ASSIGN:  AFROC  Preparations  joint  integ  preA.Numberln=AFROC  Preparations  joint  integ 

preA.Numberln  +  1: 

AFROC  Preparations  joint  integ  preA.WIP=AFROC  Preparations  joint  integ  preA.WIP+1; 
12114$  DELAY:  Triangular(30,45,60)„VA; 
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12161$  ASSIGN:  AFROC  Preparations  joint  integ  preA.NumberOut=AFROC  Preparations  joint 

integ  preA.NumberOut  +  1: 

AFROC  Preparations  joint  integ  preA.WIP=AFROC  Preparations  joint  integ  preA.WIP- 

1:NEXT(91$); 

91$  BRANCH,  1: 

With, (90)/100, 12164$, Yes: 

Else, 12165$, Yes; 

12164$  ASSIGN:  AFROC  decision  joint  integ  preA.NumberOut  True=AFROC  decision  joint  integ 

preA.NumberOut  True  +  1 
:NEXT(96$); 

12165$  ASSIGN:  AFROC  decision  joint  integ  preA.NumberOut  False=AFROC  decision  joint  integ 

preA.NumberOut  False  +  1 
:NEXT(95$); 

96$  BRANCH,  1: 

With, (25)/100, 12166$, Yes: 

Else, 12167$, Yes; 

12166$  ASSIGN:  Post  AFROC  actions  joint  integ  preA.NumberOut  True= 

Post  AFROC  actions  joint  integ  preA.NumberOut  True  +  1:NEXT(97$); 

12167$  ASSIGN:  Post  AFROC  actions  joint  integ  preA.NumberOut  False= 

Post  AFROC  actions  joint  integ  preA.NumberOut  False  +  1:NEXT(98$); 

97$  ASSIGN:  Accomplish  Post  AFROC  actions  joint  integ  preA.Numberln= 

Accomplish  Post  AFROC  actions  joint  integ  preA.Numberln  +  1: 

Accomplish  Post  AFROC  actions  joint  integ  preA.WIP= 

Accomplish  Post  AFROC  actions  joint  integ  preA.WIP+1; 

12169$  DELAY:  Triangular(l,ll,15)„VA; 

12216$  ASSIGN:  Accomplish  Post  AFROC  actions  joint  integ  preA.NumberOut= 

Accomplish  Post  AFROC  actions  joint  integ  preA.NumberOut  +  1: 

Accomplish  Post  AFROC  actions  joint  integ  preA.WIP= 

Accomplish  Post  AFROC  actions  joint  integ  preA.WIP-l:NEXT(98$); 

98$  ASSIGN:  document  signing  and  validation  joint  integ  preA.Numberln= 

document  signing  and  validation  joint  integ  preA.Numberln  +  1: 
document  signing  and  validation  joint  integ  preA.WIP= 
document  signing  and  validation  joint  integ  preA.WIP+1; 

12220$  DELAY:  Triangular(14,26,30)„VA; 

12267$  ASSIGN:  document  signing  and  validation  joint  integ  preA.NumberOut= 

document  signing  and  validation  joint  integ  preA.NumberOut  +  1: 
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document  signing  and  validation  joint  integ  preA.WIP= 
document  signing  and  validation  joint  integ  preA.WIP-l:NEXT(99$); 


99$  BRANCH,  1: 

With, (99)/100, 12270$, Yes: 

Else, 12271$, Yes; 

12270$  ASSIGN:  Final  AFROC  approval  joint  integ  preA.NumberOut  True= 

Final  AFROC  approval  joint  integ  preA.NumberOut  True  +  1:NEXT(11796$); 

12271$  ASSIGN:  Final  AFROC  approval  joint  integ  preA.NumberOut  False= 

Final  AFROC  approval  joint  integ  preA.NumberOut  False  +  1:NEXT(100$); 

100$  ASSIGN:  Final  AFROC  resolution  joint  integ  preA.Numberln= 

Final  AFROC  resolution  joint  integ  preA.Numberln  +  1: 

Final  AFROC  resolution  joint  integ  preA.WIP=Final  AFROC  resolution  joint  integ 

preA.WIP+1; 

12273$  DELAY:  Triangular(42,48,60)„VA; 

12320$  ASSIGN:  Final  AFROC  resolution  joint  integ  preA.NumberOut= 

Final  AFROC  resolution  joint  integ  preA.NumberOut  +  1: 

Final  AFROC  resolution  joint  integ  preA.WIP=Final  AFROC  resolution  joint  integ 

preA.WIP-1 

:NEXT(11796$); 

95$  BRANCH,  1: 

If, AFROC  Count==l, 12323$, Yes: 

Else, 12324$, Yes; 

12323$  ASSIGN:  Check  for  previous  path  joint  integ  preA.NumberOut  True= 

Check  for  previous  path  joint  integ  preA.NumberOut  True  +  1:NEXT(101$); 

12324$  ASSIGN:  Check  for  previous  path  joint  integ  preA.NumberOut  False= 

Check  for  previous  path  joint  integ  preA.NumberOut  False  +  1:NEXT(94$); 

101$  ASSIGN:  Kill  time  at  AFROC  joint  integ  PreA=TNOW: 

TFIN=TNOW:NEXT(102$); 

102$  TALLY:  Record  19,INT(SimTime),l:NEXT(93$); 

93$  ASSIGN:  Death  at  AFROC  joint  integ  preA.NumberOut=Death  at  AFROC  joint  integ 

preA.NumberOut  +  1; 

12325$  DISPOSE:  Yes; 

94$  ASSIGN:  AFROC  Count=l:NEXT(92$); 
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92$  BRANCH,  1: 

With, (99)/100, 12326$, Yes: 

Else, 12327$, Yes; 

12326$  ASSIGN:  Dead  activity  joint  integ  preA.NumberOut  True=Dead  activity  joint  integ 

preA.NumberOut  True  +  1 

:NEXT(101$); 

12327$  ASSIGN:  Dead  activity  joint  integ  preA.NumberOut  False=Dead  activity  joint  integ 

preA.NumberOut  False  +  1 
:NEXT(81$); 

90$  ASSIGN:  Hold  for  a  year  later  in  process  2nd  time  joint  integ  preA.Numberln= 

Hold  for  a  year  later  in  process  2nd  time  joint  integ  preA.Numberln  +  1: 

Hold  for  a  year  later  in  process  2nd  time  joint  integ  preA.WIP= 

Hold  for  a  year  later  in  process  2nd  time  joint  integ  preA.WIP+1; 

12329$  DELAY:  Triangular(270,300,365)„NVA; 

12376$  ASSIGN:  Hold  for  a  year  later  in  process  2nd  time  joint  integ  preA.NumberOut= 

Hold  for  a  year  later  in  process  2nd  time  joint  integ  preA.NumberOut  +  1: 

Hold  for  a  year  later  in  process  2nd  time  joint  integ  preA.WIP= 

Hold  for  a  year  later  in  process  2nd  time  joint  integ  preA.WIP-l:NEXT(87$); 

89$  ASSIGN:  Hold  for  a  year  later  in  process  joint  integ  preA.Numberln= 

Hold  for  a  year  later  in  process  joint  integ  preA.Numberln  +  1: 

Hold  for  a  year  later  in  process  joint  integ  preA.WIP= 

Hold  for  a  year  later  in  process  joint  integ  preA.WIP+1; 

12380$  DELAY:  Triangular(270,300,365)„NVA; 

12427$  ASSIGN:  Hold  for  a  year  later  in  process  joint  integ  preA.NumberOut= 

Hold  for  a  year  later  in  process  joint  integ  preA.NumberOut  +  1: 

Hold  for  a  year  later  in  process  joint  integ  preA.WIP= 

Hold  for  a  year  later  in  process  joint  integ  preA.WIP-l:NEXT(83$); 

11796$  ASSIGN:  Joint  Integration  PreA.NumberOut=Joint  Integration  PreA.NumberOut  +  1: 

Joint  Integration  PreA.WIP=Joint  Integration  PreA.WIP-l:NEXT(76$); 


;  Model  statements  for  module:  BasicProcess. Decide  14  (Check  Condition) 
/ 

32$  BRANCH,  1: 

If,  RequirementPathTrack>= 1,12430$, Yes: 
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Else, 12431$, Yes; 

12430$  ASSIGN:  Check  Condition. NumberOut  True=Check  Condition. NumberOut  True  + 

1:NEXT(666$); 

12431$  ASSIGN:  Check  Condition. NumberOut  False=Check  Condition. NumberOut  False  + 

1:NEXT(31$); 


;  Model  statements  for  module:  BasicProcess. Record  10  (Record  10) 
/ 

666$  TALLY:  Record  10,INT(SimTime),l:NEXT(381$); 


;  Model  statements  for  module:  BasicProcess. Assign  77  (End  Simulation  8) 
/ 

381$  ASSIGN:  Reject  in  formal  review  preA=TNOW: 

TFIN=TNOW:NEXT(382$); 


;  Model  statements  for  module:  BasicProcess. Dispose  32  (Archive  for  rejected  ideas  in  formal  review) 
/ 

382$  ASSIGN:  Archive  for  rejected  ideas  in  formal  review. NumberOut= 

Archive  for  rejected  ideas  in  formal  review. NumberOut  +  1; 

12432$  DISPOSE:  No; 


;  Model  statements  for  module:  BasicProcess. Assign  1  (Add  counter  through  feedback  path) 
/ 

31$  ASSIGN:  RequirementPathTrack=RequirementPathTrack  +  1:NEXT(30$); 


Model  statements  for  module:  BasicProcess. Decide  13  (Decision  to  Repursue) 


512 


30$  BRANCH,  1: 

With, (85)/100, 12433$, Yes: 

Else, 12434$, Yes; 

12433$  ASSIGN:  Decision  to  Repursue. NumberOut  True=Decision  to  Repursue. NumberOut  True 

+  1:NEXT(34$); 

12434$  ASSIGN:  Decision  to  Repursue. NumberOut  False=Decision  to  Repursue. NumberOut  False 

+  1:NEXT(665$); 


;  Model  statements  for  module:  BasicProcess. Process  16  (Update  Briefing  Materials) 

/ 

34$  ASSIGN:  Update  Briefing  Materials. Numberln=Update  Briefing  Materials. Numberln  +  1: 

Update  Briefing  Materials. WIP=Update  Briefing  Materials. WIP+1; 

12436$  DELAY:  Triangular(10,35,40)„VA; 

12483$  ASSIGN:  Update  Briefing  Materials. NumberOut=Update  Briefing  Materials. NumberOut  + 

1: 

Update  Briefing  Materials. WIP=Update  Briefing  Materials. WIP-1:NEXT(19$); 


;  Model  statements  for  module:  BasicProcess. Record  9  (Record  9) 
/ 

665$  TALLY:  Record  9,INT(SimTime),l:NEXT(381$); 


;  Model  statements  for  module:  BasicProcess. Process  12  (Wait  until  next  year) 

/ 

21$  ASSIGN:  Wait  until  next  year.Numberln=Wait  until  next  year. Numberln  +  1: 

Wait  until  next  year.WIP=Wait  until  next  year. WIP+1; 

12487$  DELAY:  Triangular(180,250,270)„NVA; 

12534$  ASSIGN:  Wait  until  next  year.NumberOut=Wait  until  next  year. NumberOut  +  1: 

Wait  until  next  year.WIP=Wait  until  next  year.WIP-l:NEXT(22$); 
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;  Model  statements  for  module:  BasicProcess. Assign  78  (End  Simulation  9) 
/ 

383$  ASSIGN:  Waiting  Period  End=TNOW: 

TFIN=TNOW:NEXT(676$); 


;  Model  statements  for  module:  BasicProcess. Record  35  (Record  35) 
/ 

676$  TALLY:  Record  35, INT(SimTime),l:NEXT(384$); 


;  Model  statements  for  module:  BasicProcess. Dispose  33  (End  after  waiting  period) 

/ 

384$  ASSIGN:  End  after  waiting  period. NumberOut=End  after  waiting  period. NumberOut  +  1; 

12537$  DISPOSE:  No; 


;  Model  statements  for  module:  BasicProcess. Process  10  (Route  to  Advanced  Concepts) 

/ 

16$  ASSIGN:  Route  to  Advanced  Concepts. Numberln=Route  to  Advanced  Concepts. Numberln  + 

1: 

Route  to  Advanced  Concepts. WIP=Route  to  Advanced  Concepts. WIP+1; 

12539$  DELAY:  Triangular(3,7.5,12),  Jran; 

12586$  ASSIGN:  Route  to  Advanced  Concepts. NumberOut=Route  to  Advanced 

Concepts. NumberOut  +  1: 

Route  to  Advanced  Concepts. WIP=Route  to  Advanced  Concepts. WIP-1:NEXT(13$); 


Model  statements  for  module:  BasicProcess. Create  4  (Program  review  condition) 


12589$  CREATE,  l,DaysToBaseTime(0.00),ProgramreviewpreB: 
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DaysToBaseTime((ACAT  level==l)  *TRIA(  90 , 105 , 120  )  +  (ACAT  level  ==2)  * 
TRIA(160,180,200)+  (ACAT  level  ==3)  *  TRIA(160,180,200)) 

:NEXT(12590$); 

12590$  ASSIGN:  Program  review  condition. NumberOut=Program  review  condition. NumberOut  + 

1:NEXT(373$); 


;  Model  statements  for  module:  BasicProcess. Decide  144  (Contract  started  PreB) 

/ 

373$  BRANCH,  1: 

If, contract  start==l, 12593$, Yes: 

Else, 12594$, Yes; 

12593$  ASSIGN:  Contract  started  PreB. NumberOut  True=Contract  started  PreB. NumberOut  True 

+  1:NEXT(296$); 

12594$  ASSIGN:  Contract  started  PreB. NumberOut  False=Contract  started  PreB. NumberOut 

False  +  1:NEXT(374$); 


;  Model  statements  for  module:  BasicProcess. Decide  117  (Program  Review  OK) 

/ 

296$  BRANCH,  1: 

With, (95)/100, 12595$, Yes: 

Else, 12596$, Yes; 

12595$  ASSIGN:  Program  Review  OK. NumberOut  True=Program  Review  OK. NumberOut  True  + 

1:NEXT(297$); 

12596$  ASSIGN:  Program  Review  OK. NumberOut  False=Program  Review  OK. NumberOut  False  + 

1:NEXT(298$); 


;  Model  statements  for  module:  BasicProcess. Decide  118  (Funds  Redirected) 
/ 

297$  BRANCH,  1: 

With, (20)/100,12597$, Yes: 
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Else, 12598$, Yes; 

12597$  ASSIGN:  Funds  Redirected. NumberOut  True=Funds  Redirected. NumberOut  True  + 

1:NEXT(298$); 

12598$  ASSIGN:  Funds  Redirected. NumberOut  False=Funds  Redirected. NumberOut  False  + 

1:NEXT(299$); 


;  Model  statements  for  module:  BasicProcess. Process  149  (Prepare  Courses  of  Action  PreB) 

/ 

298$  ASSIGN:  Prepare  Courses  of  Action  PreB.Numberln=Prepare  Courses  of  Action 

PreB.Numberln  +  1: 

Prepare  Courses  of  Action  PreB.WIP=Prepare  Courses  of  Action  PreB.WIP+1; 

12600$  DELAY:  Triangular(5,8,10)„VA; 

12647$  ASSIGN:  Prepare  Courses  of  Action  PreB. NumberOut=Prepare  Courses  of  Action 

PreB. NumberOut  +  1: 

Prepare  Courses  of  Action  PreB.WIP=Prepare  Courses  of  Action  PreB.WIP-l:NEXT(300$); 


;  Model  statements  for  module:  BasicProcess. Decide  121  (Determine  path  for  process  flow  Scope 
Growth  PreB) 

/ 

300$  BRANCH,  1: 

With, (80)/100, 12650$, Yes: 

Else, 12651$, Yes; 

12650$  ASSIGN:  Determine  path  for  process  flow  Scope  Growth  PreB. NumberOut  True= 

Determine  path  for  process  flow  Scope  Growth  PreB. NumberOut  True  +  1:NEXT(301$); 

12651$  ASSIGN:  Determine  path  for  process  flow  Scope  Growth  PreB. NumberOut  False= 

Determine  path  for  process  flow  Scope  Growth  PreB. NumberOut  False  +  1:NEXT(307$); 


;  Model  statements  for  module:  BasicProcess. Decide  122  (Seek  funds  PreB) 
/ 

301$  BRANCH,  1: 

With, (30)/100,12652$, Yes: 
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Else, 12653$, Yes; 

12652$  ASSIGN:  Seek  funds  PreB.NumberOut  True=Seek  funds  PreB.NumberOut  True  + 

1:NEXT(372$); 

12653$  ASSIGN:  Seek  funds  PreB.NumberOut  False=Seek  funds  PreB.NumberOut  False  + 

1:NEXT(308$); 


;  Model  statements  for  module:  BasicProcess. Process  177  (PEM  or  other  staff  find  money  PreB) 

/ 

372$  ASSIGN:  PEM  or  other  staff  find  money  PreB.Numberln=PEM  or  other  staff  find  money 

PreB.Numberln  +  1: 

PEM  or  other  staff  find  money  PreB.WIP=PEM  or  other  staff  find  money  PreB.WIP+1; 
12655$  DELAY:  (ACAT  level==l)*TRIA(14,83,180)+(ACAT  level==2)*TRIA(14,160,180)+(ACAT 

level==3)*TRIA(14,160,180)„ 

VA; 

12702$  ASSIGN:  PEM  or  other  staff  find  money  PreB.NumberOut=PEM  or  other  staff  find  money 

PreB.NumberOut  +  1: 

PEM  or  other  staff  find  money  PreB.WIP=PEM  or  other  staff  find  money  PreB.WIP- 

1:NEXT(302$); 


;  Model  statements  for  module:  BasicProcess. Decide  123  (Obtain  funds  in  a  timely  manner  PreB) 
/ 

302$  BRANCH,  1: 

With, (65)/100, 12705$, Yes: 

Else, 12706$, Yes; 

12705$  ASSIGN:  Obtain  funds  in  a  timely  manner  PreB.NumberOut  True= 

Obtain  funds  in  a  timely  manner  PreB.NumberOut  True  +  1:NEXT(305$); 

12706$  ASSIGN:  Obtain  funds  in  a  timely  manner  PreB.NumberOut  False= 

Obtain  funds  in  a  timely  manner  PreB.NumberOut  False  +  1:NEXT(306$); 


Model  statements  for  module:  BasicProcess. Assign  43  (determine  good  funding  quality  preB) 
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305$  ASSIGN:  Schedule  quality=0.045: 

funding  quality=0.045:NEXT(303$); 


;  Model  statements  for  module:  BasicProcess. Process  156  (Change  Contract  or  Rescope  contract 
PreB) 

/ 

303$  ASSIGN:  Change  Contract  or  Rescope  contract  PreB. Numberln= 

Change  Contract  or  Rescope  contract  PreB.Numberln  +  1: 

Change  Contract  or  Rescope  contract  PreB.WIP=Change  Contract  or  Rescope  contract 

PreB.WIP+1; 

12708$  DELAY:  Triangular(15,20,60)„VA; 

12755$  ASSIGN:  Change  Contract  or  Rescope  contract  PreB. NumberOut= 

Change  Contract  or  Rescope  contract  PreB.NumberOut  +  1: 

Change  Contract  or  Rescope  contract  PreB.WIP=Change  Contract  or  Rescope  contract 

PreB.WIP-1 

:NEXT(304$); 


;  Model  statements  for  module:  BasicProcess. Assign  42  (Set  cost  and  schedule  penalties) 

/ 

304$  ASSIGN:  contract  cost=contract  cost  +  (contract  cost  *  funding  quality): 

TD  Contract  length=TD  Contract  length  +  (TD  Contract  length*schedule  quality): 
TD  Contract  End  Date=TD  Contract  Start+TD  Contract  length:NEXT(364$); 


;  Model  statements  for  module:  BasicProcess. Dispose  27  (End  of  Program  Management  and 
Oversight  loop) 

/ 

364$  ASSIGN:  End  of  Program  Management  and  Oversight  loop. NumberOut= 

End  of  Program  Management  and  Oversight  loop.NumberOut  +  1; 

12758$  DISPOSE:  No; 
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;  Model  statements  for  module:  BasicProcess. Assign  44  (determine  poor  funding  quality  preB) 
/ 

306$  ASSIGN:  Schedule  quality=0.055: 

funding  quality=0.055:NEXT(303$); 


;  Model  statements  for  module:  BasicProcess. Assign  46  (Determine  quality  values  preB) 
/ 

308$  ASSIGN:  Schedule  quality=0.05: 

funding  quality=0.05:NEXT(303$); 


;  Model  statements  for  module:  BasicProcess. Decide  126  (Funding  problem  Contract  Change 
Required  preB) 

/ 

307$  BRANCH,  1: 

With, (40)/100, 12759$, Yes: 

Else, 12760$, Yes; 

12759$  ASSIGN:  Funding  problem  Contract  Change  Required  preB.NumberOut  True= 

Funding  problem  Contract  Change  Required  preB.NumberOut  True  +  1:NEXT(308$); 

12760$  ASSIGN:  Funding  problem  Contract  Change  Required  preB.NumberOut  False= 

Funding  problem  Contract  Change  Required  preB.NumberOut  False  +  1:NEXT(363$); 


;  Model  statements  for  module:  BasicProcess. Dispose  26  (End  of  contract  change  path) 
/ 

363$  ASSIGN:  End  of  contract  change  path.NumberOut=End  of  contract  change 

path.NumberOut  +  1; 

12761$  DISPOSE:  No; 


Model  statements  for  module:  BasicProcess. Dispose  24  (End  of  Program  Review  Loop) 
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299$  ASSIGN:  End  of  Program  Review  Loop.NumberOut=End  of  Program  Review 

Loop.NumberOut  +  1; 

12762$  DISPOSE:  No; 


;  Model  statements  for  module:  BasicProcess. Dispose  30  (Dispose  of  program  review  prior  to  need) 
/ 

374$  ASSIGN:  Dispose  of  program  review  prior  to  need.NumberOut= 

Dispose  of  program  review  prior  to  need.NumberOut  +  1; 

12763$  DISPOSE:  No; 


;  Model  statements  for  module:  BasicProcess. Create  5  (Uncertainty  generator  for  Event  Happens 
PreB) 


12764$  CREATE,  l,DaysToBaseTime(0), Event  Happens:DaysToBaseTime(TRIA(  30 , 60 , 90 

)):NEXT(12765$); 

12765$  ASSIGN:  Uncertainty  generator  for  Event  Happens  PreB.NumberOut= 

Uncertainty  generator  for  Event  Happens  PreB.NumberOut  +  1:NEXT(375$); 


;  Model  statements  for  module:  BasicProcess. Decide  145  (Event  Happens  PreB) 

/ 

375$  BRANCH,  1: 

If, contract  start==l, 12768$, Yes: 

Else, 12769$, Yes; 

12768$  ASSIGN:  Event  Happens  PreB.NumberOut  True=Event  Happens  PreB.NumberOut  True  + 

1:NEXT(314$); 

12769$  ASSIGN:  Event  Happens  PreB.NumberOut  False=Event  Happens  PreB.NumberOut  False  + 

1:NEXT(376$); 
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Model  statements  for  module:  BasicProcess. Decide  132  (Scope  Growth  Technical  Problems  PreB) 


314$  BRANCH,  1: 

With, (20)/100, 12770$, Yes: 

Else, 12771$, Yes; 

12770$  ASSIGN:  Scope  Growth  Technical  Problems  PreB. NumberOut  True= 

Scope  Growth  Technical  Problems  PreB. NumberOut  True  +  1:NEXT(315$); 

12771$  ASSIGN:  Scope  Growth  Technical  Problems  PreB. NumberOut  False= 

Scope  Growth  Technical  Problems  PreB. NumberOut  False  +  1:NEXT(317$); 


;  Model  statements  for  module:  BasicProcess. Separate  12  (Separate  for  logic  testing  PreB) 

/ 

315$  DUPLICATE,  100-0: 

1, 12774$, 0:NEXT(12773$); 

12773$  ASSIGN:  Separate  for  logic  testing  PreB. NumberOut  Orig=Separate  for  logic  testing 

PreB. NumberOut  Orig  +  1 

:NEXT(298$); 

12774$  ASSIGN:  Separate  for  logic  testing  PreB. NumberOut  Dup=Separate  for  logic  testing 

PreB. NumberOut  Dup  +  1 

:NEXT(317$); 


;  Model  statements  for  module:  BasicProcess. Decide  134  (Logic  check  for  ACAT  level  PreB) 

/ 

317$  BRANCH,  1: 

If, ACAT  Level==l,  12775$, Yes: 

Else, 12776$, Yes; 

12775$  ASSIGN:  Logic  check  for  ACAT  level  PreB. NumberOut  True=Logic  check  for  ACAT  level 

PreB. NumberOut  True  +  1 

:NEXT(316$); 

12776$  ASSIGN:  Logic  check  for  ACAT  level  PreB. NumberOut  False=Logic  check  for  ACAT  level 

PreB. NumberOut  False  +  1 
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:NEXT(318$); 


;  Model  statements  for  module:  BasicProcess. Decide  133  (Begin  Testing  PreB) 

/ 

316$  BRANCH,  1: 

lf,TNOW.GE.  ( (0.75*TD  original  contract  length  )  +  TD  Contract  Start ), 12777$, Yes: 
Else, 12778$, Yes; 

12777$  ASSIGN:  Begin  Testing  PreB.NumberOut  True=Begin  Testing  PreB. NumberOut  True  + 

1:NEXT(379$); 

12778$  ASSIGN:  Begin  Testing  PreB.NumberOut  False=Begin  Testing  PreB.NumberOut  False  + 

1:NEXT(319$); 


;  Model  statements  for  module:  BasicProcess. Assign  75  (Declare  start  of  T  and  E  PreB) 
/ 

379$  ASSIGN:  T  and  E  Start  PreB=l:NEXT(319$); 


;  Model  statements  for  module:  BasicProcess. Decide  136  (Query  contract  elapsed  time  6  months  to 
completion  PreB) 

/ 

319$  BRANCH,  1: 

lf,TNOW.GE.  (  TD  Contract  End  Date-180)  |  |  TD  Contract  End  Date  Near, 12779$, Yes: 
Else, 12780$, Yes; 

12779$  ASSIGN:  Query  contract  elapsed  time  6  months  to  completion  PreB.NumberOut  True= 

Query  contract  elapsed  time  6  months  to  completion  PreB.NumberOut  True  + 

1:NEXT(320$); 

12780$  ASSIGN:  Query  contract  elapsed  time  6  months  to  completion  PreB.NumberOut  False= 

Query  contract  elapsed  time  6  months  to  completion  PreB.NumberOut  False  + 

1:NEXT(322$); 
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;  Model  statements  for  module:  BasicProcess. Decide  137  (contractor  loop  PreB) 

/ 

320$  BRANCH,  1: 

lf,contractor  loop==0, 12781$, Yes: 

Else, 12782$, Yes; 

12781$  ASSIGN:  contractor  loop  PreB.NumberOut  True=contractor  loop  PreB. NumberOut  True  + 

1:NEXT(378$); 

12782$  ASSIGN:  contractor  loop  PreB.NumberOut  False=contractor  loop  PreB.NumberOut  False 

+  1:NEXT(322$); 


;  Model  statements  for  module:  BasicProcess. Assign  73  (Declare  Acq  Planning  and  Costing  to  Begin) 
/ 

378$  ASSIGN:  Acq  Plan  PreB=l: 

Costing  Begin  PreB=l:NEXT(321$); 


;  Model  statements  for  module:  BasicProcess. Assign  49  (Contractor  loop  counter  preB) 
/ 

321$  ASSIGN:  contractor  loop=contractor  loop  +1:NEXT(322$); 


;  Model  statements  for  module:  BasicProcess. Decide  138  (Contract  complete  PreB) 

/ 

322$  BRANCH,  1: 

lf,TNOW.GE.TD  Contract  End  Date  |  |  End  TD  contract, 12783$, Yes: 

Else, 12784$, Yes; 

12783$  ASSIGN:  Contract  complete  PreB.NumberOut  True=Contract  complete  PreB.NumberOut 

True  +  1:NEXT(644$); 

12784$  ASSIGN:  Contract  complete  PreB.NumberOut  False=Contract  complete  PreB.NumberOut 

False  +  1:NEXT(366$); 
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;  Model  statements  for  module:  BasicProcess. Decide  225  (First  time  to  contract  completion?) 
/ 

644$  BRANCH,  1: 

If, End  TD  contract==0, 12785$, Yes: 

Else, 12786$, Yes; 

12785$  ASSIGN:  First  time  to  contract  completion?. NumberOut  True= 

First  time  to  contract  completion?. NumberOut  True  +  1:NEXT(645$); 

12786$  ASSIGN:  First  time  to  contract  completion?. NumberOut  False= 

First  time  to  contract  completion?. NumberOut  False  +  1:NEXT(365$); 


;  Model  statements  for  module:  BasicProcess. Assign  140  (Assign  final  contract  cost) 
/ 

645$  ASSIGN:  Final  TD  contract  cost=contract  cost: 

End  TD  contract=l:NEXT(365$); 


;  Model  statements  for  module:  BasicProcess. Dispose  28  (Completion  of  contract  PreB) 
/ 

365$  ASSIGN:  Completion  of  contract  PreB.NumberOut=Completion  of  contract 

PreB. NumberOut  +  1; 

12787$  DISPOSE:  No; 


;  Model  statements  for  module:  BasicProcess. Dispose  29  (End  of  Event  Happens  Loop  PreB) 

/ 

366$  ASSIGN:  End  of  Event  Happens  Loop  PreB.NumberOut=End  of  Event  Happens  Loop 

PreB. NumberOut  +  1; 

12788$  DISPOSE:  No; 
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Model  statements  for  module:  BasicProcess. Decide  135  (Begin  Testing  ACAT  II  or  III  PreB) 


318$  BRANCH,  1: 

lf,TNOW.GE.((0.85*TD  original  contract  length  )  +  TD  Contract  Start), 12789$, Yes: 
Else, 12790$, Yes; 

12789$  ASSIGN:  Begin  Testing  ACAT  II  or  III  PreB. NumberOut  True= 

Begin  Testing  ACAT  II  or  III  PreB. NumberOut  True  +  1:NEXT(379$); 

12790$  ASSIGN:  Begin  Testing  ACAT  II  or  III  PreB. NumberOut  False= 

Begin  Testing  ACAT  II  or  III  PreB. NumberOut  False  +  1:NEXT(319$); 


;  Model  statements  for  module:  BasicProcess. Dispose  31  (Dispose  of  event  happens  prior  to  need) 
/ 

376$  ASSIGN:  Dispose  of  event  happens  prior  to  need. NumberOut= 

Dispose  of  event  happens  prior  to  need. NumberOut  +  1; 

12791$  DISPOSE:  No; 


Model  statements  for  module:  BasicProcess. Create  6  (Program  review  condition  PreC) 


12792$  CREATE,  l,DaysToBaseTime(0),ProgramreviewpreC: 

DaysToBaseTime((ACAT  level==l)  *TRIA(  90 , 105 , 120  )  +  (ACAT  level  ==2)  * 
TRIA(160,180,200)+  (ACAT  level  ==3)  *  TRIA(160,180,200)) 

:NEXT(12793$); 

12793$  ASSIGN:  Program  review  condition  PreC. NumberOut=Program  review  condition 

PreC. NumberOut  +  1:NEXT(569$); 


;  Model  statements  for  module:  BasicProcess. Decide  205  (Contract  started  PreC) 
/ 

569$  BRANCH,  1: 

If, Contract  Start  PreC==l, 12796$, Yes: 

Else, 12797$, Yes; 
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12796$  ASSIGN:  Contract  started  PreC.NumberOut  True=Contract  started  PreC.NumberOut  True 

+  1:NEXT(513$); 

12797$  ASSIGN:  Contract  started  PreC.NumberOut  False=Contract  started  PreC.NumberOut 

False  +  1:NEXT(570$); 


;  Model  statements  for  module:  BasicProcess. Decide  187  (Program  Review  OK  PreC) 

/ 

513$  BRANCH,  1: 

With, (95)/100, 12798$, Yes: 

Else, 12799$, Yes; 

12798$  ASSIGN:  Program  Review  OK  PreC.NumberOut  True=Program  Review  OK 

PreC.NumberOut  True  +  1:NEXT(514$); 

12799$  ASSIGN:  Program  Review  OK  PreC.NumberOut  False=Program  Review  OK 

PreC.NumberOut  False  +  1:NEXT(515$); 


;  Model  statements  for  module:  BasicProcess. Decide  188  (Funds  Redirected  PreC) 

/ 

514$  BRANCH,  1: 

With, (20)/100, 12800$, Yes: 

Else, 12801$, Yes; 

12800$  ASSIGN:  Funds  Redirected  PreC.NumberOut  True=Funds  Redirected  PreC.NumberOut 

True  +  1:NEXT(515$); 

12801$  ASSIGN:  Funds  Redirected  PreC.NumberOut  False=Funds  Redirected  PreC.NumberOut 

False  +  1:NEXT(516$); 


;  Model  statements  for  module:  BasicProcess. Process  232  (Prepare  Courses  of  Action  PreC) 
/ 

515$  ASSIGN:  Prepare  Courses  of  Action  PreC.Numberln=Prepare  Courses  of  Action 

PreC.Numberln  +  1: 

Prepare  Courses  of  Action  PreC.WIP=Prepare  Courses  of  Action  PreC.WIP+1; 
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12803$  DELAY:  Triangular(5,8,10)„VA; 

12850$  ASSIGN:  Prepare  Courses  of  Action  PreC.NumberOut=Prepare  Courses  of  Action 

PreC.NumberOut  +  1: 

Prepare  Courses  of  Action  PreC.WIP=Prepare  Courses  of  Action  PreC.WIP-l:NEXT(517$); 


;  Model  statements  for  module:  BasicProcess. Decide  189  (Determine  path  for  process  flow  Scope 
Growth  PreC) 

/ 

517$  BRANCH,  1: 

With, (80)/100, 12853$, Yes: 

Else, 12854$, Yes; 

12853$  ASSIGN:  Determine  path  for  process  flow  Scope  Growth  PreC.NumberOut  True= 

Determine  path  for  process  flow  Scope  Growth  PreC.NumberOut  True  +  1:NEXT(518$); 

12854$  ASSIGN:  Determine  path  for  process  flow  Scope  Growth  PreC.NumberOut  False= 

Determine  path  for  process  flow  Scope  Growth  PreC.NumberOut  False  +  1:NEXT(524$); 


;  Model  statements  for  module:  BasicProcess. Decide  190  (Seek  funds  PreC) 

/ 

518$  BRANCH,  1: 

With, (30)/100, 12855$, Yes: 

Else, 12856$, Yes; 

12855$  ASSIGN:  Seek  funds  PreC.NumberOut  True=Seek  funds  PreC.NumberOut  True  + 

1:NEXT(568$); 

12856$  ASSIGN:  Seek  funds  PreC.NumberOut  False=Seek  funds  PreC.NumberOut  False  + 

1:NEXT(525$); 


;  Model  statements  for  module:  BasicProcess. Process  251  (PEM  or  other  staff  find  money  PreC) 

/ 

568$  ASSIGN:  PEM  or  other  staff  find  money  PreC.Numberln=PEM  or  other  staff  find  money 

PreC.Numberln  +  1: 

PEM  or  other  staff  find  money  PreC.WIP=PEM  or  other  staff  find  money  PreC.WIP+1; 
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12858$  DELAY:  (ACAT  level==l)*TRIA(14,83,180)+(ACAT  level==2)*TRIA(14,160,180)+(ACAT 

level==3)*TRIA(14,160,180)„ 

VA; 

12905$  ASSIGN:  PEM  or  other  staff  find  money  PreC.NumberOut=PEM  or  other  staff  find  money 

PreC.NumberOut  +  1: 

PEM  or  other  staff  find  money  PreC.WIP=PEM  or  other  staff  find  money  PreC.WIP- 

1:NEXT(519$); 


;  Model  statements  for  module:  BasicProcess. Decide  191  (Obtain  funds  in  a  timely  manner  PreC) 
/ 

519$  BRANCH,  1: 

With, (65)/100, 12908$, Yes: 

Else, 12909$, Yes; 

12908$  ASSIGN:  Obtain  funds  in  a  timely  manner  PreC.NumberOut  True= 

Obtain  funds  in  a  timely  manner  PreC.NumberOut  True  +  1:NEXT(522$); 

12909$  ASSIGN:  Obtain  funds  in  a  timely  manner  PreC.NumberOut  False= 

Obtain  funds  in  a  timely  manner  PreC.NumberOut  False  +  1:NEXT(523$); 


;  Model  statements  for  module:  BasicProcess. Assign  95  (determine  good  funding  quality  preC) 
/ 

522$  ASSIGN:  Schedule  quality  PreC=.045: 

funding  quality  PreC=.045:NEXT(520$); 


;  Model  statements  for  module:  BasicProcess. Process  233  (Change  Contract  or  Rescope  contract 
PreC) 

/ 

520$  ASSIGN:  Change  Contract  or  Rescope  contract  PreC. Numberln= 

Change  Contract  or  Rescope  contract  PreC.Numberln  +  1: 

Change  Contract  or  Rescope  contract  PreC.WIP=Change  Contract  or  Rescope  contract 

PreC.WIP+1; 

12911$  DELAY:  Triangular(15,20,60)„VA; 

12958$  ASSIGN:  Change  Contract  or  Rescope  contract  PreC.NumberOut= 
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Change  Contract  or  Rescope  contract  PreC.NumberOut  +  1: 

Change  Contract  or  Rescope  contract  PreC.WIP=Change  Contract  or  Rescope  contract 

PreC.WIP-1 

:NEXT(521$); 


;  Model  statements  for  module:  BasicProcess. Assign  94  (Set  cost  and  schedule  penalties  PreC) 

/ 

521$  ASSIGN:  SDD  contract  cost=SDD  contract  cost  +  (SDD  contract  cost  *  funding  quality  PreC): 

SDD  contract  length=SDD  contract  length  +  (SDD  contract  length*schedule  quality  PreC): 
SDD  Contract  End  Date=SDD  Contract  Start+SDD  contract  length:NEXT(560$); 


;  Model  statements  for  module:  BasicProcess. Dispose  42  (End  of  Program  Management  and 
Oversight  loop  PreC) 

/ 

560$  ASSIGN:  End  of  Program  Management  and  Oversight  loop  PreC.NumberOut= 

End  of  Program  Management  and  Oversight  loop  PreC.NumberOut  +  1; 

12961$  DISPOSE:  No; 


;  Model  statements  for  module:  BasicProcess. Assign  96  (determine  poor  funding  quality  preC) 
/ 

523$  ASSIGN:  Schedule  quality  PreC=.055: 

funding  quality  PreC=.055:NEXT(520$); 


;  Model  statements  for  module:  BasicProcess. Assign  97  (Determine  quality  values  preC) 
/ 

525$  ASSIGN:  Schedule  quality  PreC=.05: 

funding  quality  PreC=.05:NEXT(520$); 
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;  Model  statements  for  module:  BasicProcess. Decide  192  (Funding  problem  Contract  Change 
Required  preC) 

/ 

524$  BRANCH,  1: 

With, (40)/100, 12962$, Yes: 

Else, 12963$, Yes; 

12962$  ASSIGN:  Funding  problem  Contract  Change  Required  preC.NumberOut  True= 

Funding  problem  Contract  Change  Required  preC.NumberOut  True  +  1:NEXT(525$); 

12963$  ASSIGN:  Funding  problem  Contract  Change  Required  preC.NumberOut  False= 

Funding  problem  Contract  Change  Required  preC.NumberOut  False  +  1:NEXT(559$); 


;  Model  statements  for  module:  BasicProcess. Dispose  41  (End  of  contract  change  path  PreC) 

/ 

559$  ASSIGN:  End  of  contract  change  path  PreC.NumberOut=End  of  contract  change  path 

PreC.NumberOut  +  1; 

12964$  DISPOSE:  No; 


;  Model  statements  for  module:  BasicProcess. Dispose  39  (End  of  Program  Review  Loop  PreC) 


516$  ASSIGN:  End  of  Program  Review  Loop  PreC.NumberOut=End  of  Program  Review  Loop 

PreC.NumberOut  +  1; 

12965$  DISPOSE:  No; 


;  Model  statements  for  module:  BasicProcess. Dispose  45  (Dispose  of  program  review  prior  to  need 
PreC) 

/ 

570$  ASSIGN:  Dispose  of  program  review  prior  to  need  PreC.NumberOut= 

Dispose  of  program  review  prior  to  need  PreC.NumberOut  +  1; 

12966$  DISPOSE:  No; 
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;  Model  statements  for  module:  BasicProcess. Create  7  (Uncertainty  generator  for  Event  Happens 
PreC) 


12967$  CREATE,  l,DaysToBaseTime(0), Event  Happens  2:DaysToBaseTime(TRIA(  30 , 60 , 90 
)) :  N  EXT(  12968$); 

12968$  ASSIGN:  Uncertainty  generator  for  Event  Happens  PreC.NumberOut= 

Uncertainty  generator  for  Event  Happens  PreC.NumberOut  +  1:NEXT(571$); 


;  Model  statements  for  module:  BasicProcess. Decide  206  (Event  Happens  PreC) 

/ 

571$  BRANCH,  1: 

If, Contract  Start  PreC==l, 12971$, Yes: 

Else, 12972$, Yes; 

12971$  ASSIGN:  Event  Happens  PreC.NumberOut  True=Event  Happens  PreC.NumberOut  True  + 

1:NEXT(531$); 

12972$  ASSIGN:  Event  Happens  PreC.NumberOut  False=Event  Happens  PreC.NumberOut  False  + 

1:NEXT(572$); 


;  Model  statements  for  module:  BasicProcess. Decide  194  (Scope  Growth  Technical  Problems  PreC) 
/ 

531$  BRANCH,  1: 

With, (20)/100, 12973$, Yes: 

Else, 12974$, Yes; 

12973$  ASSIGN:  Scope  Growth  Technical  Problems  PreC.NumberOut  True= 

Scope  Growth  Technical  Problems  PreC.NumberOut  True  +  1:NEXT(532$); 

12974$  ASSIGN:  Scope  Growth  Technical  Problems  PreC.NumberOut  False= 

Scope  Growth  Technical  Problems  PreC.NumberOut  False  +  1:NEXT(533$); 
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;  Model  statements  for  module:  BasicProcess. Separate  23  (Separate  for  logic  testing  PreC) 

/ 

532$  DUPLICATE,  100-0: 

1, 12977$, 0:NEXT(12976$); 

12976$  ASSIGN:  Separate  for  logic  testing  PreC.NumberOut  Orig=Separate  for  logic  testing 

PreC.NumberOut  Orig  +  1 

:NEXT(515$); 

12977$  ASSIGN:  Separate  for  logic  testing  PreC.NumberOut  Dup=Separate  for  logic  testing 

PreC.NumberOut  Dup  +  1 

:NEXT(533$); 


;  Model  statements  for  module:  BasicProcess. Decide  196  (Preliminary  Design  Review) 

/ 

533$  BRANCH,  1: 

lf,TNOW.GE.(  (  SDD  contract  length  *  .25  )  +  SDD  Contract  Start ), 12978$, Yes: 
Else, 12979$, Yes; 

12978$  ASSIGN:  Preliminary  Design  Review. NumberOut  True=Preliminary  Design 

Review. NumberOut  True  +  1:NEXT(576$); 

12979$  ASSIGN:  Preliminary  Design  Review. NumberOut  False=Preliminary  Design 

Review. NumberOut  False  +  1:NEXT(534$); 


;  Model  statements  for  module:  BasicProcess. Decide  208  (Trigger  PDR  once) 

/ 

576$  BRANCH,  1: 

If, PDR==0, 12980$, Yes: 

Else, 12981$, Yes; 

12980$  ASSIGN:  Trigger  PDR  once. NumberOut  True=Trigger  PDR  once. NumberOut  True  + 

1:NEXT(577$); 

12981$  ASSIGN:  Trigger  PDR  once. NumberOut  False=Trigger  PDR  once. NumberOut  False  + 

1:NEXT(578$); 
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;  Model  statements  for  module:  BasicProcess. Assign  110  (Change  PDR  variable) 
/ 

577$  ASSIGN:  PDR=1:NEXT(578$); 


;  Model  statements  for  module:  BasicProcess. Decide  209  (Critical  Design  Review) 

/ 

578$  BRANCH,  1: 

IfJNOW.GE.  ( (SDD  contract  length*0.45)  +  SDD  Contract  Start ), 12982$, Yes: 

Else, 12983$, Yes; 

12982$  ASSIGN:  Critical  Design  Review. NumberOut  True=Critical  Design  Review. NumberOut 

True  +  1:NEXT(579$); 

12983$  ASSIGN:  Critical  Design  Review. NumberOut  False=Critical  Design  Review. NumberOut 

False  +  1:NEXT(534$); 


;  Model  statements  for  module:  BasicProcess. Decide  210  (Trigger  CDR  once) 

/ 

579$  BRANCH,  1: 

If, CDR==0, 12984$, Yes: 

Else, 12985$, Yes; 

12984$  ASSIGN:  Trigger  CDR  once. NumberOut  True=Trigger  CDR  once. NumberOut  True  + 

1:NEXT(580$); 

12985$  ASSIGN:  Trigger  CDR  once. NumberOut  False=Trigger  CDR  once. NumberOut  False  + 

1:NEXT(534$); 


;  Model  statements  for  module:  BasicProcess. Assign  111  (Change  CDR  variable) 
/ 

580$  ASSIGN:  CDR=1:NEXT(534$); 
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;  Model  statements  for  module:  BasicProcess. Decide  198  (Query  contract  elapsed  time  6  months  to 
completion  PreC) 

/ 

534$  BRANCH,  1: 

lf,TNOW.GE.(SDD  Contract  End  Date-180)  |  |  SDD  Contract  condition  end  is 
close, 12986$, Yes: 

Else, 12987$, Yes; 

12986$  ASSIGN:  Query  contract  elapsed  time  6  months  to  completion  PreC.NumberOut  True= 

Query  contract  elapsed  time  6  months  to  completion  PreC.NumberOut  True  + 

1:NEXT(535$); 

12987$  ASSIGN:  Query  contract  elapsed  time  6  months  to  completion  PreC.NumberOut  False= 

Query  contract  elapsed  time  6  months  to  completion  PreC.NumberOut  False  + 

1:NEXT(537$); 


;  Model  statements  for  module:  BasicProcess. Decide  199  (contractor  loop  check  PreC) 

/ 

535$  BRANCH,  1: 

If, contractor  loop  PreC==0, 12988$, Yes: 

Else, 12989$, Yes; 

12988$  ASSIGN:  contractor  loop  check  PreC.NumberOut  True=contractor  loop  check 

PreC.NumberOut  True  +  1:NEXT(573$); 

12989$  ASSIGN:  contractor  loop  check  PreC.NumberOut  False=contractor  loop  check 

PreC.NumberOut  False  +  1 

:NEXT(537$); 


;  Model  statements  for  module:  BasicProcess. Assign  108  (Declare  Acq  Planning  and  Costing  to  Begin 
PreC) 

/ 

573$  ASSIGN:  Acq  Plan  PreC=l: 

Costing  Begin  PreC=l:NEXT(536$); 
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Model  statements  for  module:  BasicProcess. Assign  98  (Set  Contractor  loop  variable  preC) 


536$  ASSIGN:  contractor  loop  PreC=l:NEXT(537$); 


;  Model  statements  for  module:  BasicProcess. Decide  200  (Contract  complete  PreC) 

/ 

537$  BRANCH,  1: 

lf,TNOW.GE.SDD  Contract  End  Date  |  |  End  SDD  contract, 12990$, Yes: 

Else, 12991$, Yes; 

12990$  ASSIGN:  Contract  complete  PreC. NumberOut  True=Contract  complete  PreC.NumberOut 

True  +  1:NEXT(646$); 

12991$  ASSIGN:  Contract  complete  PreC.NumberOut  False=Contract  complete  PreC.NumberOut 

False  +  1:NEXT(562$); 


;  Model  statements  for  module:  BasicProcess. Decide  226  (Determine  final  SDD  cost) 

/ 

646$  BRANCH,  1: 

If, End  SDD  contract==0, 12992$, Yes: 

Else, 12993$, Yes; 

12992$  ASSIGN:  Determine  final  SDD  cost. NumberOut  True=Determine  final  SDD 

cost. NumberOut  True  +  1:NEXT(647$); 

12993$  ASSIGN:  Determine  final  SDD  cost. NumberOut  False=Determine  final  SDD 

cost. NumberOut  False  +  1:NEXT(561$); 


;  Model  statements  for  module:  BasicProcess. Assign  141  (Assign  final  SDD  cost) 
/ 

647$  ASSIGN:  SDD  Final  contract  cost=SDD  contract  cost: 

End  SDD  contract=l:NEXT(561$); 
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;  Model  statements  for  module:  BasicProcess. Dispose  43  (Completion  of  contract  PreC) 
/ 

561$  ASSIGN:  Completion  of  contract  PreC.NumberOut=Completion  of  contract 

PreC.NumberOut  +  1; 

12994$  DISPOSE:  No; 


;  Model  statements  for  module:  BasicProcess. Dispose  44  (End  of  Event 
/ 

562$  ASSIGN:  End  of  Event  Happens  Loop  PreC. NumberOut=End 

PreC.NumberOut  +  1; 

12995$  DISPOSE:  No; 


Happens  Loop  PreC) 
of  Event  Happens  Loop 


;  Model  statements  for  module:  BasicProcess. Dispose  46  (Dispose  of  event  happens  prior  to  need 
PreC) 

/ 

572$  ASSIGN:  Dispose  of  event  happens  prior  to  need  PreC.NumberOut= 

Dispose  of  event  happens  prior  to  need  PreC.NumberOut  +  1; 

12996$  DISPOSE:  No; 

SI  MAN  Global  Code 

PROJECT,  "Enterprise  Acquisition  Process","  Robb  Wirthlin",„No,No,No,No,No,No,No,No,No,No; 
ATTRIBUTES:  SimTime; 

VARIABLES:  Acq  Plan  PreC, CLEAR(System),CATEGORY(" User  Specified-User 
Specified"), DATATYPE(Real): 

Program  Office  Cost  Estimate  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Set  Acquisition  Program  Baseline  PreB.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 
Change  Contract  or  Rescope  contract  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 


536 


Joint  Integration  PreA.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
Finalize  RSR  and  calendar  items. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Acquisition  Panels  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Check  TRR  looping  condition. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Waiting  Period. WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Draft  document  joint  integ  preA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

End  at  MS  C.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Check  Condition  PreB. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

MAJCOM  approval  indep  preB. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Air  staff  process  indep  preC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
Preferred  System  Concept, CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real), 0.0: 

Contract  complete  PreB. NumberOut  T rue,CLEAR(Statistics),CATEGORY("Exclude"): 

Critical  comments  indep  preA.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Post  AFROC  actions  indep  preC. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Draft  document  joint  integ  preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Resolve  JROC  issues  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

MAJCOM  approval  PreC. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Air  Staff  processes  joint  int  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Joint  Interest  preA.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Document  review  phase  joint  integ  preA.NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

SRR  rework  and  delay. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Check  for  previous  path  joint  int  preC. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 
ACAT  II  Or  III  Dev  testing  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Kill  time  at  AFROC  joint  interest  preB,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Post  AFROC  actions.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Continute  other  Acquisition  Swimlane  activities  preA.NumberOut 
Orig,CLEAR(Statistics),CATEGORY("Exclude"): 

Accomplish  Post  AFROC  actions  indep  preB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
JROC  PreC. NumberOut  False,CLEAR(Statistics),CATEGORY(" Exclude"): 

Kill  time  at  AFROC  joint  interest  PreC,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Funds  set  aside  for  next  phase  in  FYDP  at  80  percent  of  ICE  amount  PreB. NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Comment  Resolution  joint  int  preC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Post  AFROC  actions  indep  preC. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Check  TRR  looping  condition. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Death  at  AFROC  joint  int  preA. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
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Air  staff  process  joint  integ  preC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Developmental  system  testing  and  Live  Fire  test  and  Operational  Assessment 
testing.  WIP,CLEAR(System),CATEGORY("Exclude-Exclude"), 

DATATYPE(Real): 

Final  AFROC  approval  joint  integ  preA.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 
AFROC  decision  indep  preA.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
Contractor  cost  estimate  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

TRR  Delay, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real): 

Logic  check  for  ACAT  level  PreB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Start  AoA  flag,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real): 
Approve  Selected  CoA.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Separate  activities  once  preC.NumberOut  Dup,CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process  indep  preA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
ACAT  1  Preparation  for  Acquisition  Panels 
preB.Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

Resolving  Flag  level  comments  PreC.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
Prepare  Courses  of  Action  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

AoA  flag,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real),0: 

AFROC  Preparations  indep  preA.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Determine  type  of  requirements  document 
needed.  NumberOut,CLEAR(Statistics),CATEGORY("  Exclude"): 

CDR  2.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  II  or  III  Preparation  for  Acquisition  Panels  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Analysis.  Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

Draft  document  joint  integ  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Joint  Capabilities  Board.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
Route  to  Advanced  Concepts. WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Check  on  conditions. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process  indep  preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
CDR  delay  2  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Critical  comments  joint  integ  preA.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 
Split  into  costing  activities  PreB.NumberOut  Orig,CLEAR(Statistics),CATEGORY("Exclude"): 

Air  Staff  processes  joint  int  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Dead  activity  joint  int  preA.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

TD  original  contract  length, CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 
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MAJCOM  A  Letters  Coordinate  and  Concur. NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Critical  Comments?  joint  int  preB. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 
Scope  and  Award  Technology  Development  Contracts. WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

MDA  Milestone  approval. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Combined  Testing. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Check  Condition. NumberOut  False,CLEAR(Statistics),CATEGORY("Exclude"): 

Separate  again  preA. NumberOut  Dup,CLEAR(Statistics),CATEGORY("Exclude"): 

Independent  document  preB.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Additional  Adjustments.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

RFP  Coordination  Process  PreC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

CDR  Rework  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

CDR  delay  2  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  level  check  preA. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Kill  at  MS  B  decision. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Resolving  flag  level  comments  joint  integ 
preC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Wait  for  more  favorable  conditions  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Acquisition  Panels  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  Preparations  indep  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Update  Briefing  Materials  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

PreRSR  MAJCOM  A8. NumberOut  False,CLEAR(Statistics),CATEGORY(" Exclude"): 

Program  Kill  at  CDR. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

CDR  delay  2  PreC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

CDR  Rework  PreC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Hold  for  a  year.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  I  time  delay  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  II  or  III  Preparation  for  Acquisition  Panels 
preB.  NumberOut,CLEAR(Statistics),CATEGORY("  Exclude"): 

Timing  of  funds  OK?. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  Preparations  joint  integ  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Draft  briefing  and  materials. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Split  into  costing  activities  PreC. NumberOut  Dup,CLEAR(Statistics),CATEGORY("Exclude"): 
Trigger  PDR  once. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

High  Performance  Team  work  preB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
Preliminary  Design  Review. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  level  check  preA. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
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ACAT  1  Preparation  for  Acquisition  Panels 
preB.NumberOut,CLEAR(Statistics),CATEGORY("  Exclude"): 

Hold  for  a  year  later  in  process  joint  integ 
preC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Engineering  Development  model, CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

ACAT  I  time  delay. NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

KPP  Development.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Wait  for  more  favorable  conditions  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Set  Acquisition  Program  Baseline  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Accomplish  Post  AFROC  actions  joint  integ 
preC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

PreRSR  MAJCOM  A8.NumberOut  True,CLEAR(Statistics),CATEGORY(" Exclude"): 

Delay  to  repeat  required  steps  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Acquisition  Planning  Activities  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Document  review  phase  2  flag  level  joint  integ 
preA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Dead  activity  indep  preA.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

document  signing  and  validation  joint  integ 
preB.NumberOut,CLEAR(Statistics),CATEGORY("  Exclude"): 

Needs  AOA  ICD  OK,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real): 

AFROC  Preparations  joint  integ  preA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

MAJCOM  approval  later  on  joint  integ  preC.NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Direct  entry  into  SDD  phase, CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Pre  MS  B  contract  length, CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real),0: 

ACAT  1  funding. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Bring  the  processes  together  PreC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  I  time  delay. WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

SDD  Final  contract  cost,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Check  for  previous  path. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  Preparations  joint  integ  preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Completion  of  contract  PreC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Contract  started  PreB. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Document  Reveiw  Phase  2  Flag  Level  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Scope  Growth  Technical  Problems  PreC.NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 
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Interoperability  Certification  joint  integ 
preB.NumberOut,CLEAR(Statistics),CATEGORY("  Exclude"): 

RFP  Coordination  Process. Numberln,CLEAR(Statistics),CATEGORY(" Exclude"): 

End  SDD  contract, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real): 
ACAT  II  Or  III  Acquisition  Planning  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 
Program  Office  Cost  Estimate  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Obtain  funds  in  a  timely  manner  PreB.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 
Critical  comments  indep  preA.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Split  flow  PreB.NumberOut  Dup,CLEAR(Statistics),CATEGORY("Exclude"): 

Determine  final  SDD  cost. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

AoA  killed, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real),0: 
Document  review  phase  2  flag  level  joint  integ  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Developmental  Test  and  Evaluation. WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Check  for  ACAT  level  for  potential  AoA. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 
Split  into  Acq  Planning  and  Costing  Activities. NumberOut 
Orig,CLEAR(Statistics),CATEGORY("Exclude"): 

Program  Review  OK. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Funds  set  aside  for  next  phase  in  FYDP  at  80  percent  of  ICE  amount  PreB.NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

Affordability  Assessment  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

RFP  Release  and  Source  Selection  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

MS  B  approval  attempt, CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real),0: 

Requires  AoA  but  not  ICD,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Check  for  previous  path  indep  preB.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 
Acquisition  Panels.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
Comment  Resolution  joint  int  preA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  II  Or  III  Dev  testing  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Check  for  previous  path  joint  integ  preC. NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

PDR  delay  2  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

MDA  Milestone  approval  PreC. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Air  staff  process  indep  preB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Comment  Resolution  joint  int  preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
Fabrication.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

SVR  rework  and  delay. WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
AFROC  decision  indep  preA.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 
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Program  Office  Cost  Estimate  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Random  Entry  Point. WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
Schedule  quality  PreC,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Begin  Testing  ACAT  II  or  III  PreB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
Random  Entry  Point. NumberOut,CLEAR(Statistics),CATEGORY(" Exclude"): 

Source  selection  plans  preB.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
Separate  for  logic  testing  PreB.NumberOut  Orig,CLEAR(Statistics),CATEGORY("Exclude"): 

SDD  Final  contract  length, CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

RSR  HQ  USAF  A5R.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Source  selection  plans  preB.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

PDR  Rework  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Check  looping  condition. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

JCB  issues. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

MAJCOM  approval  indep  preC. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Seek  funds  PreB.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Update  Briefing  Materials.NumberOut,CLEAR(Statistics),CATEGORY(" Exclude"): 

Prepare  Courses  of  Action  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Death  at  AFROC  indep  preB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
draft  document  preC  joint  interest. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Post  AFROC  actions  joint  int  preC. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

JROC  preparations  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
comment  resolution  indep  preC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

DRR  rework  and  delay. WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
AFROC  Count, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real),0: 
Short  study. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Critical  comments  joint  integ  preB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
Contract  Startup  PreB. NumberOut, CLEAR(Statistics),CATEGORY(" Exclude"): 

Check  for  ACAT  level  for  potential  AoA. NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

PEM  or  other  staff  find  money  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Waiting  Period. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

End  at  AoA  check.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Document  Review  Phase. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Post  AFROC  actions  PreC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
Draft  RFP  Preparation  preA.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
to  Acquisition  Modernization  or  Sustainment  Activity. WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Check  for  previous  MDA  decision  attempt  preA. NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 
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Check  for  previous  path  indep  preB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Functional  Capabilities  Board  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Document  review  phase  2  flag  level  joint  integ 
preB.Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

Check  for  previous  path  joint  integ  preB.NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Hold  for  a  year  later  in  process  joint  integ  preC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

PEM  or  other  staff  find  money  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Wait  until  next  year.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

PreBpursuerequirements,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real),0: 

Form  High  Performance  Team.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Post  AFROC  actions  PreB.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

JROC  PreB.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Receipt  of  approved  CPD.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Kill  at  MS  A  decision  time,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Change  Contract  or  Rescope  contract  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

T  and  E  Start  PreB,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real): 

Accomplish  Post  AFROC  actions  joint  integ 
preA.Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

Draft  document  indep  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

EOA  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Decision  to  pursue  requirements  PreC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Resolve  JCB  issues  PreB.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Post  AFROC  actions  joint  integ  preB.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Accomplish  Post  AFROC  actions  joint  integ 
preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

RFP  Coordination  Process. NumberOut,CLEAR(Statistics),CATEGORY(" Exclude"): 

Functional  Capabilities  Board  PreC.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Final  AFROC  resolution  joint  integ  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Non  AoA  Route. NumberOut  Orig,CLEAR(Statistics),CATEGORY("Exclude"): 

Set  Acquisition  Program  Baseline  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Accomplish  Post  AFROC  actions  indep  preC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Delay  for  Protest  review  PreC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

RFP  Release  and  Source  Selection  PreC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
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Determine  path  for  process  flow  Scope  Growth  PreB.NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Non  AoA  Route. NumberOut  Dup,CLEAR(Statistics),CATEGORY("Exclude"): 

Acquisition  Panels  PreC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

JCB  issues. NumberOut  False,CLEAR(Statistics),CATEGORY(" Exclude"): 

ACAT  II  or  ACAT  III  time  delay  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
Document  Reveiw  Phase  2  Flag  Level. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
Independent  document  preC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Begin  Testing  ACAT  II  or  III  PreB.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 
Resolving  Flag  level  comments. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process  2nd  time  joint  integ 
preA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Split  into  Acq  Planning  and  Costing  Activities  PreC. NumberOut 
Dup,CLEAR(Statistics),CATEGORY("Exclude"): 

First  time  to  contract  completion?. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
MAJCOM  approval  joint  integ  preB.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 
Hold  for  a  year  PreC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
Separate  for  logic  testing  PreB.NumberOut  Dup,CLEAR(Statistics),CATEGORY("Exclude"): 

Approve  Selected  CoA. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

PDR  delay  2  PreC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Funds  Redirected. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Joint  Integration  PreC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Draft  briefing  and  materials  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Dead  activity  joint  int  preB.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Document  Review  Phase  PreB.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Air  staff  process  joint  integ  preB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Second  split  into  costing  activities  PreB.NumberOut  Dup,CLEAR(Statistics),CATEGORY("Exclude"): 
Contract  Startup  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Query  contract  elapsed  time  6  months  to  completion  PreB.NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Joint  Integration  PreA.Numberln,CLEAR(Statistics),CATEGORY(" Exclude"): 

Form  High  Performance  Team  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  decision  indep  preB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Finalize  RSR  and  calendar  items  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Joint  Integration  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Delay  for  Protest  review  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Event  Happens  PreC. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

High  Performance  Team  work  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
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Resolve  JCB  issues  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

End  of  Event  Happens  Loop  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Funds  Redirected. NumberOut  False,CLEAR(Statistics),CATEGORY("Exclude"): 

Set  ACAT  level. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Complete  predecessor  activities  preA. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
Delay  for  Protest  review  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Joint  Integration  PreC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

High  Performance  Team  work  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Contract  complete  PreC. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  Decision  joint  int  preB. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  PreC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  I  Dev  testing  PreB.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
RSR  HQ  USAF  A5R. NumberOut  Fa lse,CLEAR(Statistics),CATEGORY(" Exclude"): 

Form  High  Performance  Team.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Change  Contract  or  Rescope  contract  PreC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
Split  flow  for  PreMSB. NumberOut  Orig,CLEAR(Statistics),CATEGORY("Exclude"): 

MAJCOM  Approval?  joint  int  preB. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 
Check  for  previous  MDA  decision  attempt  preB. NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

PEM  or  other  staff  find  money  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

RFP  Coordination  Process  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

AFROC  decision  joint  integ  preA. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

RSR  HQ  USAF  A5R  PreB. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Update  Briefing  Materials  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Funding  problem  Contract  Change  Required  preB. NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

Set  ACAT  level. N urn berln,CLEAR(Statistics),CATEGORY("Exclude"): 

Fabrication.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

draft  document  preA  joint  interest. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  II  or  ACAT  III  funding. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Trigger  Acquisition  swimlane  activity. NumberOut  Orig,CLEAR(Statistics),CATEGORY("Exclude"): 
AFROC  Preparations  joint  integ  preC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  II  Or  III  Acquisition  Planning  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Analysis.  NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

SVR  rework  and  delay. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  I  time  delay  PreB.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
AFROC  Preparations  joint  int  preA. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
MAJCOM  Approval?  joint  int  preA. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
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Death  at  AFROC  joint  integ  preA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Draft  document  joint  integ  preC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Finalize  RSR  and  calendar  items  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

JROC  preparations.NumberOut,CLEAR(Statistics),CATEGORY(" Exclude"): 

Uncertainty  generator  for  Event  Flappens 
PreC.NumberOut,CLEAR(Statistics),CATEGORY("  Exclude"): 

Dead  activity  joint  integ  preA.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  level  preA.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  level  check  preB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  Preparations  joint  int  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

draft  document  preB  joint  interest. NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Joint  Capabilities  Board  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process  indep  preB.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Scope  and  Award  Technology  Development 
Contracts.Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

for  Affordability  Assessment  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Killed  at  AoA,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real): 

Preliminary  Design  Review. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

MAJCOM  approval  PreB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Set  ACAT  level. Wl P,CLEAR(System),CATEGORY("Exclude-Exclude"), DAT ATYPE(Real): 

Back  into  process  at  A  time,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Decision  to  Repursue. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

draft  document  preB  joint  interest. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Dead  activity  indep  preB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  Preparations  indep  preC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

PDR,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real): 

Resolve  JCB  issues.NumberOut,CLEAR(Statistics),CATEGORY(" Exclude"): 

KPP  Development.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

comment  resolution  joint  integ  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Prepare  Courses  of  Action  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

MAJCOM  A  Letters  Coordinate  and  Concur  PreB.NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Air  Staff  processes  joint  int  preA. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Acquisition  Planning  Activities  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
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Contractor  cost  estimate  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

EOA  rework  and  delay  preB.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
Contract  started  PreC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Rejection  outright.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Independent  Cost  Estimate  PreB.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 
Independent  Cost  Estimate  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

DRR  rework  and  delay. NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Early  Operational  Assessment. Numberln,CLEAR(Statistics),CATEGORY(" Exclude"): 

Resolving  Flag  level  comments.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Processes  come  together. NumberOut,CLEAR(Statistics),CATEGORY(" Exclude"): 

Form  High  Performance  Team  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Timing  of  funds  OK?.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

PDR  delay  3  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Choose  and  recommend  a  selected  CoA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

comment  resolution  indep  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Draft  RFP  Preparation  preB.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 
contractor  loop  PreC,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Draft  document  joint  integ  preA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Joint  Capabilities  Board  PreB.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

CDR  2.NumberOut  True,CLEAR(Statistics),CATEGORY(" Exclude"): 

Document  Reveiw  Phase  2  Flag  Level  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

draft  document  preC  joint  interest.  WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Check  Condition  PreC.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Contract  complete  PreC.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Resolve  JCB  issues.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Wait  until  both  complete  preA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Delay  to  repeat  required  steps  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Check  for  ACAT  level  preA.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

MAJCOM  approval  indep  preC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Costing  Begin  PreB,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real): 
Critical  comments  indep  preB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Costing  Begin  PreC,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real): 
Logic  check  for  ACAT  level  PreB.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 
Rejection  outright.NumberOut  False,CLEAR(Statistics),CATEGORY(" Exclude"): 

ACAT  level  preA.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 
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ACAT  II  or  III  Prepare  for  Acquisition  Panels  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Wait  until  next  year.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  I  prepare  for  Acquisition  panels. NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Delay  to  Align  Funds  PreC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
to  Acquisition  Modernization  or  Sustainment 
Activity.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Document  review  phase  joint  integ  preB.NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Direct  entry  to  PreC  Phase, CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Develop  Courses  of  Action. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Check  Condition  PreB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  II  Or  III  Acquisition  Planning  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
Program  Review  OK  PreC. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Draft  RFP  Preparation  preA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Protest  award  PreB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Determine  path  for  process  flow  Scope  Growth  PreB.NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

Assembly.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Program  Kill  time  at  PDR,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Separate  activities  once  preA. NumberOut  Orig,CLEAR(Statistics),CATEGORY("Exclude"): 
comment  resolution  joint  integ  preA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Final  AFROC  approval  joint  integ  preB.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 
Draft  RFP  Preparation  preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Acq  planning  activities  depend  upon  ACAT  level  preC. NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

ACAT  I  Acquisition  Planning  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Dispose  of  program  review  prior  to  need 
PreC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Post  AFROC  actions  joint  int  preA. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
Dead  activity  joint  integ  preA. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

RSR  HQ  USAF  A5R  PreB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
comment  resolution  joint  integ  preC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Scope  Growth  Technical  Problems  PreB.NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

Joint  Interest  preA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Dead  activity  indep  preA. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 
comment  resolution  joint  integ  preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
Accomplish  Post  AFROC  actions  indep  preA. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
Separate  again  preA. NumberOut  Orig,CLEAR(Statistics),CATEGORY("Exclude"): 
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Update  and  Schedule  Calendar  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 
Resolve  JROC  issues  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Joint  Interest  preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Affordability  Assessment  PreB.Numberln,CLEAR(Statistics),CATEGORY(" Exclude"): 
Fabrication.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Check  for  previous  path  indep  preC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
Contractor  cost  estimate  PreC.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Critical  comments  joint  integ  preB.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

CDR  3.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Integrated  Testing.Numberln,CLEAR(Statistics),CATEGORY(" Exclude"): 

Split  into  costing  activities  PreC.NumberOut  Orig,CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  Decision  joint  int  preA.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Draft  document  indep  preB.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Critical  Comments?  joint  int  preC.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 
ACAT  I  Acquisition  Planning  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Split  flow  PreB.NumberOut  Orig,CLEAR(Statistics),CATEGORY("Exclude"): 

Interoperability  Certification  joint  integ  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Draft  document  indep  preA.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
Kill  at  MS  A  decision. NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Dead  activity  joint  int  preB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Joint  Interest  preC.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Program  review  condition  PreC.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  level  check  preB.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Design  Readiness  Review. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  Preparations  joint  int  preA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  II  or  III  Preparation  for  Acquisition 
Panels.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Developmental  system  testing  and  Live  Fire  test  and  Operational  Assessment 
testing.  NumberOut, CLEAR(Statistics), 

CATEGORYf'Exclude"): 

Kill  time  at  MS  C  decision, CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Event  Happens  PreB.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Develop  AoA  Plan  ACAT  I.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Death  at  AFROC  joint  int  preC. NumberOut, CLEAR(Statistics), CATEGORYf'Exclude"): 

Accomplish  Post  AFROC  actions  joint  integ  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Draft  RFP  Preparation  preC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
Resolve  JCB  issues.Numberln,CLEAR(Statistics),CATEGORY(" Exclude"): 

End  at  COA  PreA,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real): 
Analysis  of  Alternatives. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
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Determine  path.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Draft  briefing  and  materials  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Acquisition  Panels  preparation  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Resolving  flag  level  comments  joint  integ  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Comment  Resolution  joint  int  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Independent  document  preA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

RFP  Coordination  Process  PreB.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

comment  resolution  indep  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Joint  Capabilities  Board.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Resolving  flag  level  comments  joint  integ 
preB.NumberOut,CLEAR(Statistics),CATEGORY("  Exclude"): 

Hold  for  a  year  later  in  process  joint  integ 
preA.Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

Acquisition  panels  preA.NumberOut,CLEAR(Statistics),CATEGORY(" Exclude"): 

Delay  to  repeat  required  steps  PreB.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  Preparations  indep  preC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Analysis.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Finalize  RSR  and  calendar  items. WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

SDD  original  contract  length, CLEAR(System),CATEGORY("User  Specified-User 
Specified"),  DATATYPE(Real): 

MAJCOM  approval  joint  integ  preA.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

JROC  preparations  PreB.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Functional  Capabilities  Board  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Trades  Delay  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

document  signing  and  validation  joint  integ  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Develop  TandE  strategy  and  Technology  Development 
Strategy.  NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

KPP  Development  signal  PreB,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

contractor  loop  check  PreC.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  1  Preparation  for  Acquisition  Panels 
preA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Split  flow  PreC.NumberOut  Dup,CLEAR(Statistics),CATEGORY("Exclude"): 

SDD  contract  cost,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real): 

Continue  until  completion  and  End  of 
process.  NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 
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Hold  for  a  year  later  in  process  2nd  time  joint  integ 
preB.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Joint  Capabilities  Board  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

draft  document  preA  joint  interest. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
Accomplish  Post  AFROC  actions  joint  integ 
preB.NumberOut,CLEAR(Statistics),CATEGORY("  Exclude"): 

Trades  Delay, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real): 

Seek  funds  PreB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Critical  Comments?  joint  int  preA.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
draft  document  preC  joint  interest. NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Dev  testing  rework  and  delay. WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

SRR  rework  and  delay. NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Wait  for  more  favorable  conditions  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 
RFP  Release  and  Source  Selection  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
Update  and  Schedule  Calendar  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Obtain  funds  in  a  timely  manner  PreC.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 
Critical  comments  indep  preB.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Resolve  JROC  issues  PreB.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
ACAT  I  prepare  for  Acquisition  panels. WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Critical  Design  Review. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process  indep  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

trade  counter, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real): 
PreRSR  MAJCOM  A8  PreB.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  II  or  ACAT  III  time  delay.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  Decision  joint  int  preC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Delay  to  Align  Funds  PreC.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Assembly.  WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Check  for  previous  path. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Funds  Available  preA.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Air  staff  process  indep  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Developmental  system  testing  and  Live  Fire  test  and  Operational  Assessment 
testing.  Numberln,CLEAR(Statistics), 

CATEGORYf'Exclude"): 

Prepare  Concept  of  Operation. NumberOut, CLEAR(Statistics), CATEGORYf'Exclude"): 

Acquisition  Planning  Activities  PreC. Numberln,CLEAR(Statistics), CATEGORYf'Exclude"): 

Check  for  previous  MDA  decision  attempt  preC.NumberOut 
False, CLEAR(Statistics), CATEGORYf'Exclude"): 
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Selected  CoA  Kill  point, CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real),0: 

Final  AFROC  resolution  joint  integ  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
Program  Office  Cost  Estimate  PreB.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 
Document  review  phase  2  flag  level  joint  integ 
preC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Check  for  previous  path  indep  preC.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 
Form  High  Performance  Team  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Joint  Interest  preB.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Develop  AoA  Plan.Numberln,CLEAR(Statistics),CATEGORY(" Exclude"): 

Program  Review  OK.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

MS  A  approval  attempt, CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real),0: 

Update  and  Schedule  Calendar  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

RFP  Coordination  Process  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

DRR  Success, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real): 
Analysis  of  Alternatives.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Independent  Cost  Estimate  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Concept  Decision  and  ADM. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Final  AFROC  resolution  joint  integ  preC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
Determine  final  SDD  cost. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

End  of  Program  Management  and  Oversight  loop 
PreC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

First  time  to  contract  completion?. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 
Resolve  JROC  issues. NumberOut, CLEAR(Statistics),CATEGORY(" Exclude"): 

AFROC  decision  indep  preB. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Draft  briefing  and  materials  PreC.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

PDR  Rework  time,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real): 
Separate  for  logic  testing  PreC.NumberOut  Orig,CLEAR(Statistics),CATEGORY("Exclude"): 
Independent  document  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

CDR  Rework  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Post  AFROC  actions. WIP,CLEAR(System),CATEGORY("Exclude-Exclude"), DAT ATYPE(Real): 

ACAT  II  or  III  Preparation  for  Acquisition 
Panels.Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

Study  for  ICD  Development. WIP,CLEAR(System),CATEGORY("Exclude-Exclude"), DAT ATYPE(Real): 
Route  to  Proper  Organization. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Change  Contract  or  Rescope  contract  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Seek  funds  PreC.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Waiting  Period. Numberln,CLEAR(Statistics),CATEGORY(" Exclude"): 
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Trigger  CDR  once.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  level  preB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Receipt  of  approved  CCD.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Query  contract  elapsed  time  6  months  to  completion  PreB.NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

Air  staff  process  indep  preA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Prepare  Concept  of  Operation. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Air  staff  process  indep  preB.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Decision  to  pursue  requirements. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Resolving  Flag  level  comments  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Critical  comments  joint  integ  preC. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

PDR  success??.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Test  Readiness  Review. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Final  AFROC  approval  joint  integ  preA. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Decision  to  pursue  requirements  PreB.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Check  for  previous  MDA  decision  attempt  preB.NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

ACAT  I  Acquisition  Planning  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Death  at  AFROC  indep  preA. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  II  or  III  Prepare  for  Acquisition  Panels 
preA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Comment  Resolution  joint  int  preB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

comment  resolution  indep  preB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Check  for  previous  path  joint  integ  preC. NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Update  and  Schedule  Calendar. WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

TD  final  contract  length, CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Hold  for  a  year. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

MAJCOM  A  Letters  Coordinate  and  Concur. NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

JROC  PreC. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  Preparations  joint  int  preC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Resolving  Flag  level  comments  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  decision  joint  integ  preA. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

MDA  Milestone  approval. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Air  staff  process  joint  integ  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 
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Check  for  previous  path  joint  int  preA.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
Post  AFROC  actions  joint  integ  preC.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 
Resolving  Flag  level  comments  PreB.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 
Contract  started  PreB.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 
comment  resolution  joint  integ  preC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Document  review  phase  joint  integ  preA.NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

Interoperability  Certification  joint  integ  preA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
Archive  for  rejected  ideas  in  formal  review. NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 
Separate  for  logic  testing  PreC.NumberOut  Dup,CLEAR(Statistics),CATEGORY("Exclude"): 
Determine  path  for  process  flow  Scope  Growth  PreC.NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Obtain  funds  in  a  timely  manner  PreB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
AFROC  Preparations  joint  int  preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
Interoperability  Certification  joint  integ  preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
Air  Staff  processes  joint  int  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

JROC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Document  Reveiw  Phase  2  Flag  Level  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
Hold  for  a  year  later  in  process  2nd  time  joint  integ 
preB.Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

Second  split  into  costing  activities  PreC.NumberOut  Dup,CLEAR(Statistics),CATEGORY("Exclude"): 
Conduct  AoA.NumberOut  False,CLEAR(Statistics),CATEGORY(" Exclude"): 

Functional  Capabilities  Board  PreB.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Post  AFROC  actions  indep  preA.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 
MAJCOM  approval  joint  integ  preC.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 
Critical  comments  indep  preC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Draft  briefing  and  materials. WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
funding  quality, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real),0: 
document  signing  and  validation  joint  integ 
preA.Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

System  Requirements  Review. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Form  High  Performance  Team. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Delay  for  Protest  review  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

RFP  Release  and  Source  Selection  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
Contract  Startup  PreC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Hold  for  a  year  later  in  process  joint  integ 
preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

High  Performance  Team  work  preA. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

End  prior  to  start  of  Requirements  swimlane 
PreC.N  urn  berOut,CLEAR(Statistics),CATEGORY("  Exclude"): 
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Dead  activity  joint  int  preC.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Document  Review  Phase  PreC.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

document  signing  and  validation  joint  integ 
preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  Preparations  joint  integ  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Query  contract  elapsed  time  6  months  to  completion  PreC.NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Choose  and  recommend  a  selected  CoA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process  joint  integ 
preB.NumberOut,CLEAR(Statistics),CATEGORY("  Exclude"): 

Protest  award  PreC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  1  Preparation  for  Acquisition  Panels  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Check  for  previous  path  joint  int  preA.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Dev  testing  rework  and  delay. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

CDR  success??. NumberOut  False,CLEAR(Statistics),CATEGORY("Exclude"): 

Early  Operational  Assessment. WIP,CLEAR(System), CATEGORYf  Exclude- 
Exclude"),DATATYPE(Real): 

Wait  for  more  favorable  conditions. WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

AFROC  Preparations  indep  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Post  AFROC  actions  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

MS  A  decision  time,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Reai),0: 

Post  AFROC  actions  joint  int  preB. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Develop  TandE  strategy  and  Technology  Development 
Strategy.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Scope  Growth  Technical  Problems  PreC.NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

document  signing  and  validation  joint  integ 
preA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Air  staff  process  joint  integ  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  decision  indep  preC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Acquisition  Planning  Activities  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

contractor  loop,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real),0: 

Resolving  flag  level  comments  joint  integ 
preB.Numberln,CLEAR(Statistics), CATEGORYf'  Exclude"): 

Dev  testing  rework  and  delay. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Test  Readiness  Review. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
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Completion  of  contract  PreB.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

MAJCOM  Approval?  joint  int  preC.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 
Wait  until  next  year.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

End  Process  at  COA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Accomplish  Post  AFROC  actions  indep  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
Hold  for  a  year  later  in  process  2nd  time  joint  integ 
preC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

In  Scope  of  Existing  document?. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
Interoperability  Certification  joint  integ 
preA.  NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Source  selection  plans  preA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  decision  joint  integ  preB. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

RSR  HQ  USAF  A5R  PreC.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Funds  Redirected  PreC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

End  of  Event  Happens  Loop  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Early  Archive, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real): 
ACAT  II  Or  III  Acquisition  Planning  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
MDA  Milestone  approval  PreB. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 
MAJCOM  approval.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Acquisition  Panels  PreB. Numberln,CLEAR(Statistics),CATEGORY(" Exclude"): 

Dead  activity  joint  int  preC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Source  selection  plans  preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Funding  problem  Contract  Change  Required  preC.NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

OR  junction. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Program  Office  Cost  Estimate  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  II  or  ACAT  III  time  delay  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Funding  problem  Contract  Change  Required  preB. NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Post  AFROC  actions  joint  integ  preA. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
MAJCOM  A  Letters  Coordinate  and  Concur  PreB. NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

Affordability  Assessment  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Document  review  phase  2  flag  level  joint  integ  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Draft  document  joint  integ  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

PDR  delay  2  PreC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Study  for  ICD  Development. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

PDR  2. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 
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Develop  Courses  of  Action. NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

MAJCOM  Approval?  joint  int  preB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
Dead  activity  joint  integ  preB.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 
Complete  predecessor  activities  preC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

DRR  loop,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real): 

Air  Staff  processes  joint  int  preA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Separate  activities  once  preA.NumberOut  Dup,CLEAR(Statistics),CATEGORY("Exclude"): 

Check  DRR  looping  condition. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

End  of  contract  change  path. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Resolve  JROC  issues  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Draft  document  indep  preC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
MAJCOM  approval  later  on  joint  integ  preA.NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

Air  Staff  processes  joint  int  preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Functional  Capabilities  Board. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Update  Briefing  Materials  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

MAJCOM  approval  PreC. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Dev  testing  activities  depend  upon  ACAT  level  preB.NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Program  Office  Cost  Estimate  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Back  into  process  at  C  time,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Source  selection  plans  preA. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

EOA  rework  and  delay  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Contractor  cost  estimate  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

MAJCOM  A  Letters  Coordinate  and  Concur  PreC. NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Dead  activity  indep  preC. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

PDR  2. NumberOut  False,CLEAR(Statistics),CATEGORY(" Exclude"): 

Source  selection  plans  preA.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
MAJCOM  approval  later  on  joint  integ  preA.NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Update  Briefing  Materials.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process  indep  preA. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
ACAT  1  Preparation  for  Acquisition  Panels 
preA.Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

OR  junction.NumberOut  False,CLEAR(Statistics),CATEGORY("Exclude"): 

CPD  Time,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real): 

AFROC  Preparations  joint  int  preC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Initial  Rate  Production  Baseline. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Develop  AoA  Plan  ACAT  I. NumberOut, CLEAR(Statistics),CATEGORY(" Exclude"): 
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Hold  for  a  year  later  in  process  indep  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
Death  at  AFROC  joint  integ  preC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 
PreCpursuerequirements,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Prepare  Courses  of  Action  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Request  for  Funds  between  August  and  December. NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

System  Requirements  Review. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Short  study. NumberOut, CLEAR(Statistics),CATEGORY(" Exclude"): 

document  signing  and  validation  joint  integ  preC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Route  to  Advanced  Concepts. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Finalize  RSR  and  calendar  items. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Develop  AoA  Plan.NumberOut,CLEAR(Statistics),CATEGORY(" Exclude"): 
to  Acquisition  Modernization  or  Sustainment 
Activity.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

JCB  issues  PreB. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

CDR  3. NumberOut  True,CLEAR(Statistics),CATEGORY(" Exclude"): 

Post  AFROC  actions  PreB.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
draft  document  preB  joint  interest. WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Draft  briefing  and  materials. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process  joint  integ  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Continute  other  Acquisition  Swimlane  activities  preA. NumberOut 
Dup,CLEAR(Statistics),CATEGORY("Exclude"): 

Begin  Testing  PreB. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Decision  to  pursue  requirements. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
Split  into  Acq  Planning  and  Costing  Activities  PreC. NumberOut 
Orig,CLEAR(Statistics),CATEGORY("Exclude"): 

PDR  rework, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real): 

CDR  Rework  time,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real): 
ACAT  I  prepare  for  Acquisition  panels. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
Acquisition  Panels  preparation  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

AcqPanelTry,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real),0: 
ACAT  level  preB. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Air  Staff  processes  joint  int  preC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  I  time  delay  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Concept  Decision  and  ADM. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Decision  to  Repursue  PreB. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
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Document  review  phase  joint  integ  preC.NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Resolve  JCB  issues  PreC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Develop  AoA  Plan  ACAT  I.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Hold  for  a  year  later  in  process. NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Post  AFROC  actions  indep  preA.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Final  AFROC  resolution  joint  integ  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Kill  by  MDA  at  Concept  Decision  PreA,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DAT  ATYPE(Real): 

Accomplish  Post  AFROC  actions  indep  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Separate  activities  once  preB.NumberOut  Orig,CLEAR(Statistics),CATEGORY("Exclude"): 

Check  Condition  PreC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Design  Readiness  Review. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Affordability  Assessment  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

ACAT  II  or  ACAT  III  time  delay. WIP,CLEAR(System), CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

DRR  Rework, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real): 

Final  AFROC  approval  joint  integ  preC.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Delay  to  repeat  required  steps  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Acquisition  Panels  PreB.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

KPP  Development. WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Determine  path  for  process  flow  Scope  Growth  PreC.NumberOut 
False,  CLEAR(Statistics),CATEGORY("Exclude"): 

MAJCOM  approval  indep  preA.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Scope  and  Award  System  Design  and  Development 
Contracts.  NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  Preparations  joint  integ  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Dead  activity  indep  preB.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Draft  document  joint  integ  preC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Post  AFROC  actions  joint  int  preA.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Fully  funded  to  80%  ICE  in  FYDP?  PreC.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Protest  upheld  PreC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Independent  document  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

contractor  loop  PreB.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  level  check  for  Acquisition  swimlane  preA.NumberOut 
False,  CLEAR(Statistics),CATEGORY("Exclude"): 

Dead  activity  joint  integ  preB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

RSR  HQ  USAF  A5R  PreC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
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Hold  for  a  year  later  in  process  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  I  time  delay  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process. WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

PreRSR  MAJCOM  A8  PreB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  PreB.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Dispose  of  event  happens  prior  to  need 
PreC.NumberOut,CLEAR(Statistics),CATEGORY("  Exclude"): 

Schedule  quality, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real),0: 

Processes  come  together  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Air  staff  process  joint  integ  preA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Scope  and  Award  Technology  Development 
Contracts.  NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  I  Acquisition  Planning  PreB.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Critical  comments  joint  integ  preC.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Joint  Integration  PreB.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

comment  resolution  joint  integ  preB.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

SVR  rework, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real): 

AFROC  Decision  joint  int  preB.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Finish  in  Sustainment, CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Split  flow  PreC.NumberOut  Orig,CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  decision  joint  integ  preB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

TRR  Delay  PreC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Kill  time  at  AFROC  joint  integ  PreA,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Resolve  JROC  issues  PreB.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Joint  Integration  PreB.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Delay  for  Protest  review  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Kill  time  at  AFROC  joint  integ  PreB,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

MDAP  Threshold  crossed?. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  II  or  III  Prepare  for  Acquisition  Panels 
preA.Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

Kill  time  at  AFROC  joint  integ  PreC,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Event  Happens  PreC.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Dev  testing  activities  depend  upon  ACAT  level  preB.NumberOut 
False,  CLEAR(Statistics),CATEGORY("Exclude"): 

Resolve  JROC  issues.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
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Start  model. NumberOut,CLEAR(Statistics),CATEGORY(" Exclude"): 

High  Performance  Team  work  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Scope  of  Existing  CCD,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Change  Contract  or  Rescope  contract  PreB.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Draft  document  indep  preA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Document  review  phase  joint  integ  preB.NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

Comment  Resolution  joint  int  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

System  Verification  Review. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Obtain  funds  in  a  timely  manner  PreC. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Joint  Interest  preB.NumberOut, CLEAR(Statistics),CATEGORY(" Exclude"): 

Pre  DRR  Acquisition  Panels. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  I  Dev  testing  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Accomplish  Post  AFROC  actions  indep  preC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Assembly.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Prepare  Concept  of  Operation. WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

RFP  Coordination  Process  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

AFROC  Preparations  joint  integ  preB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  Count  PreB,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real),0: 

AFROC  Count  PreC,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real): 

JROC  preparations  PreB. Numberln,CLEAR(Statistics),CATEGORY(" Exclude"): 

MAJCOM  approval  joint  integ  preB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Wait  for  a  year.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

PDR  success??.NumberOut  Fa lse,CLEAR(Statistics),CATEGORY(" Exclude"): 

Preparation  for  Acqiusition  Panels  before 
DRR.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Protest  award  PreB.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  II  or  ACAT  III  time  delay  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

TRR  loop,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real): 

Document  Reveiw  Phase  2  Flag  Level. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Draft  document  joint  integ  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Uncertainty  generator  for  Event  Happens 
PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Finalize  RSR  and  calendar  items  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Split  flow  for  PreMS  C. NumberOut  Dup,CLEAR(Statistics),CATEGORY("Exclude"): 
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Air  Staff  processes  joint  int  preC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

TD  Contract  End  Date,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

For  existing  Program?. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

for  Affordability  Assessment  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

TRR  Delay  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

CPD,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real): 

Route  to  Advanced  Concepts. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Document  Review  Phase. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Document  review  phase  2  flag  level  joint  integ 
preA.Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

Critical  comments  indep  preC. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Protest  upheld  PreC. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Seek  funds  PreC. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Critical  Comments?  joint  int  preB. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

PDR  Rework  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Functional  Capabilities  Board.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Back  into  process  at  PreA,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

contract  cost,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real),0: 

MDAP  Threshold  crossed?. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Trades  Needed. NumberOut  False,CLEAR(Statistics),CATEGORY(" Exclude"): 

Back  into  process  at  PreB,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Change  Contract  or  Rescope  contract  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Draft  document  indep  preA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

PreRSR  MAJCOM  A8  PreC.NumberOut  True, CLEAR(Statistics),CATEGORY(" Exclude"): 

Finalize  RSR  and  calendar  items  PreC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Functional  Capabilities  Board  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Document  review  phase  2  flag  level  joint  integ 
preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Independent  document  preC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  Preparations  indep  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Update  Briefing  Materials  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Back  into  process  at  PreC,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Longer  Study. Numberln,CLEAR(Statistics),CATEGORY(" Exclude"): 
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AFROC  Preparations  joint  integ  preC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Prepare  Courses  of  Action  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Accomplish  Post  AFROC  actions  joint  integ 
preB.Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

Draft  document  indep  preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Wait  for  more  favorable  conditions. NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

TRR  Delay  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Contractor  cost  estimate  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Second  split  into  costing  activities  PreB.NumberOut  Orig,CLEAR(Statistics),CATEGORY("Exclude"): 

Acq  planning  activities  depend  upon  ACAT  level  preB.NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

Set  Acquisition  Program  Baseline  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

MAJCOM  approval.NumberOut  False,CLEAR(Statistics),CATEGORY("Exclude"): 

Check  for  previous  path  joint  integ  preA.NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

AFROC  decision  indep  preC.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

StarttimeofAoA,CLEAR(System),CATEGORY("User  Specified-User  Specified"),DATATYPE(Real),0: 

Draft  RFP  Preparation  preA.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Set  Acquisition  Program  Baseline  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

PDR  Rework  PreC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

End  of  Program  Review  Loop.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Document  Review  Phase  PreB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Early  Operational  Assessment. NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Document  review  phase  2  flag  level  joint  integ 
preB.NumberOut,CLEAR(Statistics),CATEGORY("  Exclude"): 

Check  looping  condition. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Update  Briefing  Materials. WIP,CLEAR(System),CATEGORY("Exclude-Exclude"), DAT ATYPE(Real): 

System  Performance  Specification, CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Acquisition  Panels.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Developmental  Test  and  Evaluation. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  II  or  ACAT  III  time  delay  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

MAJCOM  Approval?  joint  int  preC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Make  Trades?. NumberOut  True, CLEAR(Statistics),CATEGORY(" Exclude"): 

Final  AFROC  resolution  joint  integ  preB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Kill  at  begin  of  requirements  swimlane  PreB,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 
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End  of  Program  Management  and  Oversight 
loop.  NumberOut,CLEAR(Statistics),CATEGORY("  Exclude"): 

End  after  waiting  period. NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Draft  briefing  and  materials  PreB.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Integrated  Testing.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Kill  at  Begin  of  requirements  swimlane  PreC,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

Contract  Startup  PreB.Numberln,CLEAR(Statistics),CATEGORY(" Exclude"): 

ACAT  level  preC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

PDR  delay  3  PreC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Final  TD  contract  cost,CLEAR(System),CATEGORY("User  Specified-User 
Specified"),  DATATYPE(Real): 

Query  contract  elapsed  time  6  months  to  completion  PreC.NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

MAJCOM  approval  later  on  joint  integ  preB.NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

Check  on  conditions  PreC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

TD  Contract  Start, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real): 
SDD  Contract  Start, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real): 
Funds  Redirected  PreC.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Decision  to  pursue  requirements  PreC.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 
Check  for  previous  MDA  decision  attempt  preC.NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Document  review  phase  2  flag  level  joint  integ  preC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

funding  quality  PreC,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

ACAT  I  time  delay. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Finalize  RSR  and  calendar  items  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Joint  Integration  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

High  Performance  Team  work  preA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

RFP  Release  and  Source  Selection  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Critical  Design  Review. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Final  AFROC  approval  joint  integ  preB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
TD  Contract  length, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real): 
contractor  loop  PreB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

High  Performance  Team  work  preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Resolve  JCB  issues  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

JROC  preparations  PreC.NumberOut, CLEAR(Statistics),CATEGORY(" Exclude"): 

Delay  for  Protest  review  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Set  Acquisition  Program  Baseline  PreC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
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EOA  rework  and  delay  preB.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

PEM  or  other  staff  find  money  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
Document  Reveiw  Phase  2  Flag  Level. WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Contract  started  PreC.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Comment  Resolution  joint  int  preA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Update  and  Schedule  Calendar  PreB.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Check  for  previous  path  joint  int  preB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
Decision  to  Repursue  PreB.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  II  or  III  Preparation  for  Acquisition  Panels 
preB.Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

Kill  by  MDA  at  Concept  Decision. NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Contractor  cost  estimate  PreB.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Source  selection  plans  preC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
Update  Briefing  Materials  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Check  Condition. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Resolving  Flag  level  comments. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
contractor  loop  check  PreC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  II  or  ACAT  III  time  delay.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 
Interoperability  Certification  joint  integ  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Prepare  Courses  of  Action  PreC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

KPPs  Ready  PreB,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real): 
Post  AFROC  actions  indep  preB.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 
Determine  type  of  requirements  document 
needed.  Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

Death  at  AFROC  indep  preC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

KPPs  Ready  PreC,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real): 
testinglength,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real),0: 
CompletetimeofAoA,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real),0: 

Death  at  AFROC  joint  int  preB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

CDR  success??. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

MS  B  decision  time,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real),0: 

Determine  path. NumberOut  False,CLEAR(Statistics),CATEGORY(" Exclude"): 

Joint  Capabilities  Board  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Integrated  Testing.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Accomplish  Post  AFROC  actions  joint  integ  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Draft  RFP  Preparation  preB.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
ICD  Time,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real),0: 
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MAJCOM  approval  PreB.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

JROC  PreB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Check  for  previous  path  joint  int  preB.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Resolving  flag  level  comments  joint  integ 
preA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  II  or  ACAT  III  funding. NumberOut  True,CLEAR(Statistics),CATEGORY(" Exclude"): 

for  funding  check  PreC. NumberOut  Dup,CLEAR(Statistics),CATEGORY("Exclude"): 

Resolving  flag  level  comments  joint  integ  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Comment  Resolution  joint  int  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

PEM  or  other  staff  find  money  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

AFROC  Preparations  indep  preB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

comment  resolution  indep  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Wait  for  a  year.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Pre  DRR  Acquisition  Panels.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Developmental  Test  and  Evaluation. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Post  AFROC  actions  PreC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

for  funding  check  PreC. NumberOut  Orig,CLEAR(Statistics),CATEGORY("Exclude"): 

Independent  Cost  Estimate  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Post  AFROC  actions  joint  int  preC. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Dead  activity  joint  integ  preC. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

In  Scope  of  Existing  document?. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process  joint  integ 
preA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Check  on  conditions. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

PreRSR  MAJCOM  A8  PreC.NumberOut  False,CLEAR(Statistics),CATEGORY(" Exclude"): 

Check  for  ACAT  level  preA. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  II  Or  III  Dev  testing  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Final  AFROC  resolution  joint  integ  preC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Accomplish  Post  AFROC  actions  joint  integ 
preA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Form  High  Performance  Team  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process  2nd  time  joint  integ 
preA.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

comment  resolution  indep  preA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  decision  joint  integ  preC.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 
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Acquisition  Panels  PreC.NumberOut,CLEAR(Statistics),CATEGORY(" Exclude"): 

Scope  and  Award  System  Design  and  Development 
Contracts.Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

SDD  contract  length, CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

JCB  issues  PreB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Combined  Testing. WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

TD  Contract  End  Date  Near, CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DAT  ATYPE(Real): 

Reject  in  formal  review  preA,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

SDD  Contract  End  Date, CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

MDA  Milestone  approval  PreC.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

comment  resolution  indep  preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Waiting  Period  End,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real): 

Critical  Comments?  joint  int  preA.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Separate  activities  once  preB.NumberOut  Dup,CLEAR(Statistics),CATEGORY("Exclude"): 

High  Performance  Team  work  preC.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

SDD  Contract  condition  end  is  close, CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

EOA  PreB.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Funding  problem  Contract  Change  Required  preC.NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Hold  for  a  year  later  in  process  indep  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

JROC  preparations. WIP,CLEAR(System),CATEGORY("Exclude-Exclude"), DAT ATYPE(Real): 

Initial  Rate  Production  Baseline. WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

SRR  rework  and  delay. WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Develop  AoA  Plan.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

ACAT  1  funding. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Longer  Study. NumberOut, CLEAR(Statistics),CATEGORY(" Exclude"): 

Kill  at  MS  C  decision. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Analysis  of  Alternatives.  WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

CCD,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real),0: 

Post  AFROC  actions  joint  integ  preB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

MAJCOM  A  Letters  Coordinate  and  Concur  PreC.NumberOut 
False,  CLEAR(Statistics),CATEGORY("Exclude"): 

Wait  for  RFP  Coord  Process  to  end. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

PDR  3. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 


567 


Draft  briefing  and  materials  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Update  and  Schedule  Calendar. NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Dead  activity  joint  integ  preC.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 
document  signing  and  validation  joint  integ 
preC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Program  Kill  at  PDR.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Form  High  Performance  Team  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Joint  Interest  preA.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

PreB  CCD  OK,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real): 
Trigger  PDR  once. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Study  for  ICD  Development. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

End  TD  contract, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real): 
Document  Reveiw  Phase  2  Flag  Level  PreC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
Form  High  Performance  Team  PreC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  II  Or  III  Acquisition  Planning  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Draft  RFP  Preparation  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

MAJCOM  approval  joint  integ  preC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
Interoperability  Certification  joint  integ 
preC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

High  Performance  Team  work  preC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

ACAT  Level, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real),l: 
Complete  predecessor  activities  preB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Split  into  costing  activities  PreB. NumberOut  Dup,CLEAR(Statistics),CATEGORY("Exclude"): 

Check  DRR  looping  condition. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

System  Verification  Review. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

MAJCOM  approval  later  on  joint  integ  preB. NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

comment  resolution  joint  integ  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Final  PDR. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Contract  Start  PreC,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real): 
PDR  3. NumberOut  False,CLEAR(Statistics),CATEGORY(" Exclude"): 

Joint  Interest  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Route  to  Proper  Organization. WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Request  for  Funds  between  August  and  December. NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

Check  on  conditions  PreC.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Air  staff  process  indep  preA.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
Trigger  CDR  once. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
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Scope  Growth  Technical  Problems  PreB.NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

ACAT  II  Or  III  Acquisition  Planning  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Dispose  of  event  happens  prior  to  need.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 
Critical  Comments?  joint  int  preC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
Affordability  Assessment  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Resolving  Flag  level  comments  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

ACAT  I  time  delay  PreC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
Prepare  for  Acquisition. WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
MS  C  approval  attempt, CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

ACAT  I  Acquisition  Planning  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
draft  document  preA  joint  interest.  WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

JROC  preparations.Numberln,CLEAR(Statistics),CATEGORY(" Exclude"): 

Wait  for  more  favorable  conditions. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Split  flow  for  PreMS  C.NumberOut  Orig,CLEAR(Statistics),CATEGORY("Exclude"): 

JCB  issues  PreC.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Route  to  Proper  Organization. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Functional  Capabilities  Boa rd.Numberln,CLEAR(Statistics),CATEGORY(" Exclude"): 
comment  resolution  indep  preA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Random  Entry  Point. Numberln,CLEAR(Statistics),CATEGORY(" Exclude"): 

Protest  upheld.NumberOut  False,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  I  Acquisition  Planning  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Prepare  for  Acquisition. Numberln,CLEAR(Statistics),CATEGORY(" Exclude"): 

Air  staff  process  indep  preC.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Kill  time  at  MS  B  decision, CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

PreC  Baseline, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real): 
Joint  Capabilities  Board.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  Preparations  joint  int  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

MAJCOM  approval  indep  preA.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
Wait  for  a  year.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Split  flow  for  PreMSB.NumberOut  Dup,CLEAR(Statistics),CATEGORY("Exclude"): 

Check  for  previous  path  indep  preA.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 
MDA  Milestone  approval  PreB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
Source  selection  plans  preC.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
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Air  staff  process  joint  integ  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

ACAT  level  preC.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Update  and  Schedule  Calendar. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Dispose  of  program  review  prior  to  need.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 
Resolve  JROC  issues. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Draft  briefing  and  materials  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Document  Review  Phase  PreC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
Contract  Startup  PreC.NumberOut, CLEAR(Statistics),CATEGORY(" Exclude"): 

Funds  Available  preA.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
comment  resolution  joint  integ  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Program  Review  OK  PreC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Decision  to  Repursue  PreC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

PEM  or  other  staff  find  money  PreC.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 
Separate  activities  once  preC.NumberOut  Orig,CLEAR(Statistics),CATEGORY("Exclude"): 

Post  AFROC  actions  indep  preB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
for  funding  check.NumberOut  Dup,CLEAR(Statistics),CATEGORY("Exclude"): 

Short  study. WIP,CLEAR(System),CATEGORY("Exclude-Exclude"), DAT ATYPE(Real): 

Conduct  AoA.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

MAJCOM  approval  indep  preB.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 
Acquisition  Planning  Activities  PreC.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Dead  activity  indep  preC.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Post  AFROC  actions  joint  int  preB.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Fully  funded  to  80%  ICE  in  FYDP?  PreC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
Longer  Study. WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Check  for  previous  path  indep  preA.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
End  prior  to  start  of  Requirements  swimlane 
PreB.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

RFP  Release  and  Source  Selection  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
Contract  Startup  PreB.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
Resolve  JCB  issues  PreC.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Make  Trades?. NumberOut  False,CLEAR(Statistics),CATEGORY(" Exclude"): 

Document  Reveiw  Phase  2  Flag  Level  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Final  AFROC  approval  joint  integ  preC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
AFROC  Decision  joint  int  preC.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  1  Preparation  for  Acquisition  Panels  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Check  for  previous  path  joint  integ  preA.NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Decision  to  pursue  requirements  PreB.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
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For  existing  Program?. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  I  time  delay  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  II  or  III  Preparation  for  Acquisition  Panels. WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Kill  time  at  AFROC  indep  PreA,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

CDR,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real): 

EOA  success, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real): 
ICD,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real),0: 

Air  staff  process  indep  preA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  I  Dev  testing  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Delay  to  repeat  required  steps  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Scope  and  Award  System  Design  and  Development 
Contracts.  WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Kill  time  at  AFROC  indep  PreB,CLEAR(System),CATEGORY("User  Specified-User 
Specified"),  DATATYPE(Real): 

Program  review  condition. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Processes  come  together  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Acquisition  Planning  Activities  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

RFP  Coordination  Process. WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
Kill  time  at  AFROC  indep  preC,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

End  of  contract  change  path  PreC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Final  AFROC  resolution  joint  integ  preA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
Additional  Adjustments.NumberOut  False,CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  decision  joint  integ  preC. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Post  AFROC  actions.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Trigger  Acquisition  swimlane  activity. NumberOut  Dup,CLEAR(Statistics),CATEGORY("Exclude"): 
Air  staff  process  indep  preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Back  into  process  at  B  time,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

MS  C  decision  time,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DAT ATYPE(Real): 
Begin  Testing  PreB. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Post  AFROC  actions  joint  integ  preA. NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 
RFP  Coordination  Process  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  level  check  for  Acquisition  swimlane  preA. NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Final  AFROC  resolution  joint  integ  preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process  2nd  time  joint  integ 
preB.NumberOut,CLEAR(Statistics),CATEGORY("  Exclude"): 

Update  and  Schedule  Calendar  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
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PDR  delay  3  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Joint  Integration  PreA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Document  review  phase  joint  integ  preC.NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

Independent  document  preA.Numberln,CLEAR(Statistics),CATEGORY(" Exclude"): 

Air  staff  process  joint  integ  preC.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Independent  document  preC.Numberln,CLEAR(Statistics),CATEGORY(" Exclude"): 

RequirementPathTrackPreB,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real),0: 

ACAT  II  or  ACAT  III  time  delay  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Kill  at  AFROC  joint  interest  PreA,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

RequirementPathTrackPreC,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 

MAJCOM  approval  joint  integ  preA.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Protest  award  PreC.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

End  of  Program  Review  Loop  PreC.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  Preparations  joint  integ  preA.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Trades  Needed. NumberOut  True, CLEAR(Statistics),CATEGORY(" Exclude"): 

Pre  DRR  Acquisition  Panels. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Dead  activity  joint  int  preA.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

Acq  planning  activities  depend  upon  ACAT  level  preB. NumberOut 
True, CLEAR(Statistics),CATEGORY("  Exclude"): 

Event  Happens  PreB. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Bring  three  processes  together  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Interoperability  Certification  joint  integ  preC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Draft  document  indep  preB.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Draft  document  indep  preC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Update  Briefing  Materials  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

ACAT  II  or  ACAT  III  time  delay  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Preparation  for  Acqiusition  Panels  before  DRR.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Resolving  Flag  level  comments  PreB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Protest  upheld.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Contract  complete  PreB. NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  Decision  joint  int  preA.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Accomplish  Post  AFROC  actions  joint  integ  preC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Program  Kill  Time  at  CDR,CLEAR(System),CATEGORY("User  Specified-User 
Specified"), DATATYPE(Real): 
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Early  Archive  End.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Check  for  previous  MDA  decision  attempt  preA.NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

for  funding  check.NumberOut  Orig,CLEAR(Statistics),CATEGORY("Exclude"): 

Delay  to  Align  Funds  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Second  split  into  costing  activities  PreC.NumberOut  Orig,CLEAR(Statistics),CATEGORY("Exclude"): 

Resolving  flag  level  comments  joint  integ  preC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Comment  Resolution  joint  int  preC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

MAJCOM  Approval?  joint  int  preA.NumberOut  True, CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  Preparations  joint  int  preB.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Split  into  Acq  Planning  and  Costing  Activities. NumberOut 
Dup,CLEAR(Statistics),CATEGORY("Exclude"): 

JCB  issues  PreC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

comment  resolution  indep  preC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Acquisition  Pa nels.Numberln,CLEAR(Statistics),CATEGORY(" Exclude"): 

Death  at  AFROC  joint  integ  preB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Finalize  RSR  and  calendar  items  PreB. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Develop  TandE  strategy  and  Technology  Development 
Strategy.Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

AFROC  Preparations  joint  int  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Acq  planning  activities  depend  upon  ACAT  level  preC.NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

JROC  preparations  PreC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Interoperability  Certification  joint  integ  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Check  for  previous  path  joint  integ  preB. NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

Initial  Rate  Production  Baseline. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Delay  to  repeat  required  steps  PreC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Functional  Capabilities  Board  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

JROC.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process  2nd  time  joint  integ 
preA.Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

document  signing  and  validation  joint  integ  preB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Choose  and  recommend  a  selected  CoA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process  indep  preC. NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Decision  to  Repursue. NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 
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Preparation  for  Acqiusition  Panels  before 
DRR.NumberOut,CLEAR(Statistics),CATEGORY("  Exclude"): 

Document  Reveiw  Phase  2  Flag  Level  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process  2nd  time  joint  integ 
preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Post  AFROC  actions  joint  integ  preC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  later  in  process  2nd  time  joint  integ 
preC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Joint  Capabilities  Board  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Hold  for  a  year  later  in  process  joint  integ  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Trades  Delay  PreC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Develop  Courses  of  Action.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Hold  for  a  year  later  in  process  joint  integ 
preB.Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

document  signing  and  validation  joint  integ 
preB.Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

Critical  comments  joint  integ  preA.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 

Air  Staff  processes  joint  int  preB.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Trades  Delay  PreC.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Update  and  Schedule  Calendar  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Independent  Cost  Estimate  PreC.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

Resolve  JROC  issues  PreC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

contract  start, CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real),0: 

AFROC  Preparations  indep  preA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

EOA  PreB.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Final  PDR.NumberOut  False,CLEAR(Statistics),CATEGORY(" Exclude"): 

Hold  for  a  year  later  in  process  indep  preC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Determine  type  of  requirements  document  needed. WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

MAJCOM  approval  later  on  joint  integ  preC.NumberOut 
False,CLEAR(Statistics),CATEGORY("  Exclude"): 

Resolve  JCB  issues  PreB.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 

Air  staff  process  joint  integ  preA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Final  AFROC  resolution  joint  integ  preA.NumberOut, CLEAR(Statistics),CATEGORY("Exclude"): 

AFROC  Preparations  indep  preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Prepare  for  Acquisition. NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Hold  for  a  year  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Post  AFROC  actions  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
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Accomplish  Post  AFROC  actions  indep  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Air  staff  process  joint  integ  preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Draft  RFP  Preparation  preC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

SVR  rework  and  delay. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Joint  Interest  preC.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
Affordability  Assessment  PreB.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

RequirementPathTrack,CLEAR(System),CATEGORY("User  Specified-User 
Specified"),  DATATYPE(Real),0: 

Resolving  flag  level  comments  joint  integ 
preA.Numberln,CLEAR(Statistics),CATEGORY("  Exclude"): 

Draft  document  joint  integ  preB.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Joint  Capabilities  Board  PreC.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Acquisition  panels  preA.WIP,CLEAR(System),CATEGORY("Exclude-Exclude"),DATATYPE(Real): 
DRR  rework  and  delay. Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

CCD  Time, CLEAR(System),CATEGORY(" User  Specified-User  Specified"), DAT ATYPE(Real),0: 
Accomplish  Post  AFROC  actions  indep  preA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
Hold  for  a  year  later  in  process  PreB.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 
Combined  Testing. NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

Independent  Cost  Estimate  PreC.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Resolving  flag  level  comments  joint  integ 
preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Independent  document  preA.WIP,CLEAR(System),CATEGORY("Exclude- 
Exclude"),DATATYPE(Real): 

Decision  to  Repursue  PreC.NumberOut  True,CLEAR(Statistics),CATEGORY("Exclude"): 

Acquisition  Panels  preparation  PreC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
Accomplish  Post  AFROC  actions  indep  preC.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 
Acquisition  panels  preA.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Source  selection  plans  preB.Numberln,CLEAR(Statistics),CATEGORY("Exclude"): 

Check  for  previous  path  joint  int  preC.NumberOut  False, CLEAR(Statistics),CATEGORY("Exclude"): 
Acq  Plan  PreB,CLEAR(System),CATEGORY("User  Specified-User  Specified"), DATATYPE(Real): 
comment  resolution  joint  integ  preA.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"): 

JROC  preparations  PreB.NumberOut,CLEAR(Statistics),CATEGORY("Exclude"); 

QUEUES:  KPPs  arrive  from  Requirements. Queue, FIFO„AUTOSTATS(Yes„): 

Wait  for  PDR.Queue,FIFO„AUTOSTATS(Yes„): 

Bring  the  processes  together  PreC. Queue, FIFO„AUTOSTATS(Yes„): 

Wait  for  successful  Design  Readiness  Review  Indep  PreC. Queue, FIFO„AUTOSTATS(Yes„): 

Wait  for  successful  Design  Readiness  Review  Joint  PreC. Queue, FIFO„AUTOSTATS(Yes„): 
Processes  come  together  PreB. Queue, FIFO„AUTOSTATS(Yes„): 
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Processes  come  together. Queue, FIFO„AUTOSTATS(Yes„): 

Wait  for  AoA  Start.Queue,FIFO„AUTOSTATS(Yes„): 

Complete  predecessor  activities  preA. Queue, FIFO„AUTOSTATS(Yes„): 

Wait  for  T  and  E  Start.Queue,FIFO„AUTOSTATS(Yes„): 

Wait  for  RFP  Coord  Process  to  end. Queue, FIFO„AUTOSTATS(Yes„): 

KPPs  arrive  from  Requirements  PreC. Queue, FIFO„AUTOSTATS(Yes„): 

Complete  predecessor  activities  preB. Queue, FIFO„AUTOSTATS(Yes„): 

Wait  for  EOA  completion. Queue, FIFO„AUTOSTATS(Yes„): 

Processes  come  together  PreC. Queue, FIFO„AUTOSTATS(Yes„): 

Wait  for  contract  complete. Queue, FIFO„AUTOSTATS(Yes„): 

Wait  for  successful  Design  Readiness  Review  Interest  PreC. Queue, FIFO„AUTOSTATS(Yes„): 
Complete  predecessor  activities  preC. Queue, FIFO„AUTOSTATS(Yes„): 

Bring  three  processes  together  PreB. Queue, FIFO„AUTOSTATS(Yes„): 
for  Affordability  Assessment  PreB. Queue, FIFO„AUTOSTATS(Yes„): 

Wait  until  both  complete  preA.Queue,FIFO„AUTOSTATS(Yes„): 

Receipt  of  approved  CPD. Queue, FIFO„AUTOSTATS(Yes„): 

Wait  for  Baseline  set  PreC. Queue, FIFO„AUTOSTATS(Yes„): 

for  Affordability  Assessment  PreC. Queue, FIFO„AUTOSTATS(Yes„): 

Wait  for  signal  for  Costing  and  Acquisition  Planning  activities 
PreB. Queue,  FIFO,,  AUTOSTATS(Yes„): 

Wait  for  T  and  E  signal. Queue, FIFO„AUTOSTATS(Yes„): 

Receipt  of  approved  CCD. Queue, FIFO„AUTOSTATS(Yes„): 

Wait  for  CDR.Queue,FIFO„AUTOSTATS(Yes„): 

Wait  for  signal  for  Costing  and  Acquisition  Planning  activities 
PreC. Queue,  FIFO,,  AUTOSTATS(Yes„); 

PICTURES:  Picture. Airplane: 

Picture. Green  Ball: 

Picture. Blue  Page: 

Picture.Telephone: 

Picture. Blue  Ball: 

Picture.Yellow  Page: 

Picture. EMail: 

Picture.Yellow  Ball: 

Picture. Bike: 

Picture. Report: 

Picture.Van: 

Picture. Widgets: 

Picture. Envelope: 

Picture. Fax: 

Picture.Truck: 

Picture. Person: 
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Picture. Letter: 

Picture. Box: 

Picture. Woman: 

Picture. Package: 

Picture. Man: 

Picture. Diskette: 

Picture. Boat: 

Picture. Red  Page: 

Picture. Ball: 

Picture. Green  Page: 

Picture. Red  Ball; 

TALLIES:  Record  36„DATABASE(, "Interval", "User  Specified", "Record  36"): 

Record  37„DATABASE(, "Interval", "User  Specified", "Record  37"): 
Record  38„DATABASE(, "Interval", "User  Specified", "Record  38"): 
Record  39„DATABASE(, "Interval", "User  Specified", "Record  39"): 
Record  40„DATABASE(, "Interval", "User  Specified", "Record  40"): 
Record  41„DATABASE(, "Interval", "User  Specified", "Record  41"): 
Record  1„DATABASE(, "Interval", "User  Specified", "Record  1"): 
Record  2„DATABASE(, "Interval", "User  Specified", "Record  2"): 
Record  3„DATABASE(, "Interval", "User  Specified", "Record  3"): 
Record  4„DATABASE(, "Interval", "User  Specified", "Record  4"): 
Record  5„DATABASE(, "Interval", "User  Specified", "Record  5"): 
Record  6„DATABASE(, "Interval", "User  Specified", "Record  6"): 
Record  7„DATABASE(, "Interval", "User  Specified", "Record  7"): 
Record  8„DATABASE(, "Interval", "User  Specified", "Record  8"): 
Record  9„DATABASE(, "Interval", "User  Specified", "Record  9"): 
Record  10„DATABASE(, "Interval", "User  Specified", "Record  10"): 
Record  11„DATABASE(, "Interval", "User  Specified", "Record  11"): 
Record  12„DATABASE(, "Interval", "User  Specified", "Record  12"): 
Record  13„DATABASE(, "Interval", "User  Specified", "Record  13"): 
Record  14„DATABASE(, "Interval", "User  Specified", "Record  14"): 
Record  15„DATABASE(, "Interval", "User  Specified", "Record  15"): 
Record  16„DATABASE(, "Interval", "User  Specified", "Record  16"): 
Record  17„DATABASE(, "Interval", "User  Specified", "Record  17"): 
Record  18„DATABASE(, "Interval", "User  Specified", "Record  18"): 
Record  19„DATABASE(, "Interval", "User  Specified", "Record  19"): 
Record  20„DATABASE(, "Interval", "User  Specified", "Record  20"): 
Record  21„DATABASE(, "Interval", "User  Specified", "Record  21"): 
Record  22„DATABASE(, "Interval", "User  Specified", "Record  22"): 
Record  23„DATABASE(, "Interval", "User  Specified", "Record  23"): 
Record  24„DATABASE(, "Interval", "User  Specified", "Record  24"): 
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Record  25„DATABASE(, "Interval", "User  Specified", "Record  25"): 

Record  26„DATABASE(, "Interval", "User  Specified", "Record  26"): 

Record  33„DATABASE(, "Interval", "User  Specified", "Record  33"): 

Record  34„DATABASE(, "Interval", "User  Specified", "Record  34"): 

Record  35„DATABASE(, "Interval", "User  Specified", "Record  35"); 

DSTATS:  Acq  Plan  PreC,Acq  Plan  PreC  Value„DATABASE(, "Variable", "User  Specified", "Acq  Plan 

PreC"): 

Preferred  System  Concept, Preferred  System  Concept  Value„DATABASE(, "Variable", "User 
Specified", 

"Preferred  System  Concept"): 

Kill  time  at  AFROC  joint  interest  preB,Kill  time  at  AFROC  joint  interest  preB 
Value„DATABASE(, "Variable", 

"User  Specified", "Kill  time  at  AFROC  joint  interest  preB"): 

Kill  time  at  AFROC  joint  interest  PreC, Kill  time  at  AFROC  joint  interest  PreC 
Value„DATABASE(, "Variable", 

"User  Specified", "Kill  time  at  AFROC  joint  interest  PreC"): 

TRR  Delay, TRR  Delay  Value„DATABASE(, "Variable", "User  Specified", "TRR  Delay"): 

Start  AoA  flag, Start  AoA  flag  Value„DATABASE(, "Variable", "User  Specified", "Start  AoA  flag"): 

AoA  flag, AoA  flag  Value„DATABASE(, "Variable", "User  Specified", "AoA  flag"): 

TD  original  contract  length, TD  original  contract  length  Value„DATABASE(, "Variable", "User 
Specified", 

"TD  original  contract  length"): 

Engineering  Development  model, Engineering  Development  model 
Value,,  DATABASE^  "Variable",  "User  Specified", 

"Engineering  Development  model"): 

Direct  entry  into  SDD  phase, Direct  entry  into  SDD  phase  Value„DATABASE(, "Variable", "User 
Specified", 

"Direct  entry  into  SDD  phase"): 

Pre  MS  B  contract  length, Pre  MS  B  contract  length  Value„DATABASE(, "Variable", "User 
Specified", 

"Pre  MS  B  contract  length"): 

SDD  Final  contract  cost, SDD  Final  contract  cost  Value„DATABASE(, "Variable", "User  Specified", 

"SDD  Final  contract  cost"): 

End  SDD  contract, End  SDD  contract  Value„DATABASE(, "Variable", "User  Specified", "End  SDD 
contract"): 

AoA  killed, AoA  killed  Value„DATABASE(, "Variable", "User  Specified", "AoA  killed"): 

MS  B  approval  attempt, MS  B  approval  attempt  Value„DATABASE(, "Variable", "User 
Specified", "MS  B  approval  attempt"): 

Requires  AoA  but  not  ICD, Requires  AoA  but  not  ICD  Value„DATABASE(, "Variable", "User 
Specified", 

"Requires  AoA  but  not  ICD"): 
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Schedule  quality  PreC, Schedule  quality  PreC  Value„DATABASE(, "Variable", "User 
Specified", "Schedule  quality  PreC"): 

SDD  Final  contract  length, SDD  Final  contract  length  Value„DATABASE(, "Variable", "User 
Specified", 

"SDD  Final  contract  length"): 

AFROC  Count, AFROC  Count  Value„DATABASE(, "Variable", "User  Specified", "AFROC  Count"): 

PreBpursuerequirements,PreBpursuerequirements  Value„DATABASE(,  "Variable", "User 
Specified", 

"PreBpursuerequirements"): 

Kill  at  MS  A  decision  time, Kill  at  MS  A  decision  time  Value„DATABASE(, "Variable", "User 
Specified", 

"Kill  at  MS  A  decision  time"): 

T  and  E  Start  PreB,T  and  E  Start  PreB  Value„DATABASE(, "Variable", "User  Specified","!  and  E 
Start  PreB"): 

Killed  at  AoA, Killed  at  AoA  Value„DATABASE(, "Variable", "User  Specified", "Killed  at  AoA"): 

Back  into  process  at  A  time, Back  into  process  at  A  time  Value„DATABASE(, "Variable", "User 
Specified", 

"Back  into  process  at  A  time"): 

PDR,PDR  Value„DATABASE(, "Variable", "User  Specified", "PDR"): 

contractor  loop  PreC, contractor  loop  PreC  Value„DATABASE(, "Variable", "User 
Specified", "contractor  loop  PreC"): 

Costing  Begin  PreB, Costing  Begin  PreB  Value„DATABASE(, "Variable", "User  Specified", "Costing 
Begin  PreB"): 

Costing  Begin  PreC, Costing  Begin  PreC  Value„DATABASE(, "Variable", "User  Specified", "Costing 
Begin  PreC"): 

Program  Kill  time  at  PDR, Program  Kill  time  at  PDR  Value„DATABASE(, "Variable", "User  Specified", 

"Program  Kill  time  at  PDR"): 

Kill  time  at  MS  C  decision, Kill  time  at  MS  C  decision  Value„DATABASE(, "Variable", "User 
Specified", 

"Kill  time  at  MS  C  decision"): 

End  at  COA  PreA,End  at  COA  PreA  Value„DATABASE(, "Variable", "User  Specified", "End  at  COA 

PreA"): 

SDD  original  contract  length, SDD  original  contract  length  Value„DATABASE(, "Variable", "User 
Specified", 

"SDD  original  contract  length"): 

KPP  Development  signal  PreB,KPP  Development  signal  PreB  Value„DATABASE(, "Variable", "User 
Specified", 

"KPP  Development  signal  PreB"): 

SDD  contract  cost, SDD  contract  cost  Value„DATABASE(, "Variable", "User  Specified", "SDD 
contract  cost"): 

Trades  Delay, Trades  Delay  Value„DATABASE(, "Variable", "User  Specified", "Trades  Delay"): 

trade  countertrade  counter  Value„DATABASE(, "Variable", "User  Specified", "trade  counter"): 
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Selected  CoA  Kill  point, Selected  CoA  Kill  point  Value„DATABASE(, "Variable", "User  Specified", 
"Selected  CoA  Kill  point"): 

MS  A  approval  attempt, MS  A  approval  attempt  Value„DATABASE(, "Variable", "User 
Specified", "MS  A  approval  attempt"): 

DRR  Success, DRR  Success  Value„DATABASE(, "Variable", "User  Specified", "DRR  Success"): 

PDR  Rework  time,PDR  Rework  time  Value„DATABASE(, "Variable", "User  Specified", "PDR  Rework 

time"): 

TD  final  contract  length, TD  final  contract  length  Value„DATABASE(, "Variable", "User  Specified", 
"TD  final  contract  length"): 

funding  quality, funding  quality  Value„DATABASE(, "Variable", "User  Specified", "funding  quality"): 
MS  A  decision  time, MS  A  decision  time  Value„DATABASE(, "Variable", "User  Specified", "MS  A 
decision  time"): 

contractor  loop, contractor  loop  Value„DATABASE(, "Variable", "User  Specified", "contractor 

loop"): 

Early  Archive, Early  Archive  Value„DATABASE(, "Variable", "User  Specified", "Early  Archive"): 

DRR  loop, DRR  loop  Value„DATABASE(, "Variable", "User  Specified", "DRR  loop"): 

Back  into  process  at  C  time, Back  into  process  at  C  time  Value„DATABASE(, "Variable", "User 
Specified", 

"Back  into  process  at  C  time"): 

CPD  Time,CPD  Time  Value„DATABASE(, "Variable", "User  Specified", "CPD  Time"): 
PreCpursuerequirements,PreCpursuerequirements  Value,,  DATABASE^  "Variable",  "User 
Specified", 

"PreCpursuerequirements"): 

PDR  rework, PDR  rework  Value„DATABASE(, "Variable", "User  Specified", "PDR  rework"): 

CDR  Rework  time,CDR  Rework  time  Value„DATABASE(, "Variable", "User  Specified", "CDR  Rework 

time"): 

AcqPanelTry,AcqPanelTry  Value,, DATABASE^ "Variable", "User  Specified","AcqPanelTry"): 

Kill  by  MDA  at  Concept  Decision  PreA, Kill  by  MDA  at  Concept  Decision  PreA 
Value„DATABASE(, "Variable", 

"User  Specified", "Kill  by  MDA  at  Concept  Decision  PreA"): 

DRR  Rework, DRR  Rework  Value„DATABASE(, "Variable", "User  Specified", "DRR  Rework"): 
Schedule  quality, Schedule  quality  Value„DATABASE(, "Variable", "User  Specified", "Schedule 
quality"): 

SVR  rework, SVR  rework  Value„DATABASE(, "Variable", "User  Specified", "SVR  rework"): 

Finish  in  Sustainment, Finish  in  Sustainment  Value„DATABASE(, "Variable", "User 
Specified", "Finish  in  Sustainment"): 

Kill  time  at  AFROC  joint  integ  PreA, Kill  time  at  AFROC  joint  integ  PreA 
Value„DATABASE(, "Variable", 

"User  Specified", "Kill  time  at  AFROC  joint  integ  PreA"): 

Kill  time  at  AFROC  joint  integ  PreB,Kill  time  at  AFROC  joint  integ  PreB 
Value„DATABASE(, "Variable", 

"User  Specified", "Kill  time  at  AFROC  joint  integ  PreB"): 
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Kill  time  at  AFROC  joint  integ  PreC,Kill  time  at  AFROC  joint  integ  PreC 
Value„DATABASE(, "Variable", 

"User  Specified", "Kill  time  at  AFROC  joint  integ  PreC"): 

Scope  of  Existing  CCD, Scope  of  Existing  CCD  Value„DATABASE(, "Variable", "User 
Specified", "Scope  of  Existing  CCD"): 

AFROC  Count  PreB, AFROC  Count  PreB  Value„DATABASE(, "Variable", "User  Specified", "AFROC 
Count  PreB"): 

AFROC  Count  PreC, AFROC  Count  PreC  Value„DATABASE(, "Variable", "User  Specified", "AFROC 
Count  PreC"): 

TRR  loop,TRR  loop  Value„DATABASE(, "Variable", "User  Specified", "TRR  loop"): 

TD  Contract  End  Date,TD  Contract  End  Date  Value„DATABASE(, "Variable", "User  Specified", "TD 
Contract  End  Date"): 

CPD,CPD  Value„DATABASE(, "Variable", "User  Specified", "CPD"): 

Back  into  process  at  PreA,Back  into  process  at  PreA  Value„DATABASE(, "Variable", "User 
Specified", 

"Back  into  process  at  PreA"): 

contract  cost, contract  cost  Value„DATABASE(, "Variable", "User  Specified", "contract  cost"): 

Back  into  process  at  PreB, Back  into  process  at  PreB  Value„DATABASE(, "Variable", "User 
Specified", 

"Back  into  process  at  PreB"): 

Back  into  process  at  PreC, Back  into  process  at  PreC  Value„DATABASE(, "Variable", "User 
Specified", 

"Back  into  process  at  PreC"): 

StarttimeofAoA,StarttimeofAoA  Value,,  DATABASE^  "Variable",  "User 
Specified",  "StarttimeofAoA"): 

System  Performance  Specification, System  Performance  Specification 
Value„DATABASE(, "Variable", "User  Specified", 

"System  Performance  Specification"): 

Kill  at  begin  of  requirements  swimlane  PreB, Kill  at  begin  of  requirements  swimlane  PreB 
Value,,  DATABASE^ 

"Variable", "User  Specified", "Kill  at  begin  of  requirements  swimlane  PreB"): 

Kill  at  Begin  of  requirements  swimlane  PreC, Kill  at  Begin  of  requirements  swimlane  PreC 
Value,,  DATABASE^ 

"Variable", "User  Specified", "Kill  at  Begin  of  requirements  swimlane  PreC"): 

Final  TD  contract  cost, Final  TD  contract  cost  Value„DATABASE(, "Variable", "User  Specified", 

"Final  TD  contract  cost"): 

TD  Contract  Start, TD  Contract  Start  Value„DATABASE(, "Variable", "User  Specified", "TD  Contract 

Start"): 

SDD  Contract  Start, SDD  Contract  Start  Value„DATABASE(, "Variable", "User  Specified", "SDD 
Contract  Start"): 

funding  quality  PreC, funding  quality  PreC  Value„DATABASE(, "Variable", "User 
Specified", "funding  quality  PreC"): 
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TD  Contract  length, TD  Contract  length  Value„DATABASE(, "Variable", "User  Specified", "TD 
Contract  length"): 

KPPs  Ready  PreB,KPPs  Ready  PreB  Value„DATABASE(, "Variable", "User  Specified", "KPPs  Ready 

PreB"): 

KPPs  Ready  PreC,KPPs  Ready  PreC  Value„DATABASE(, "Variable", "User  Specified", "KPPs  Ready 

PreC"): 

testinglength,testinglength  Value„DATABASE(, "Variable", "User  Specified","testinglength"): 
CompletetimeofAoA,CompletetimeofAoA  Value„DATABASE(,  "Variable", "User 
Specified",  "CompletetimeofAoA"): 

MS  B  decision  time, MS  B  decision  time  Value„DATABASE(, "Variable", "User  Specified", "MS  B 
decision  time"): 

ICD  Time, ICD  Time  Value„DATABASE(, "Variable", "User  Specified", "ICD  Time"): 

SDD  contract  length, SDD  contract  length  Value„DATABASE(, "Variable", "User  Specified", "SDD 
contract  length"): 

TD  Contract  End  Date  Near,TD  Contract  End  Date  Near  Value„DATABASE(, "Variable", "User 
Specified", 

"TD  Contract  End  Date  Near"): 

Reject  in  formal  review  preA, Reject  in  formal  review  preA  Value„DATABASE(, "Variable", "User 
Specified", 

"Reject  in  formal  review  preA"): 

SDD  Contract  End  Date, SDD  Contract  End  Date  Value„DATABASE(, "Variable", "User 
Specified", "SDD  Contract  End  Date"): 

Waiting  Period  End, Waiting  Period  End  Value„DATABASE(, "Variable", "User  Specified", "Waiting 
Period  End"): 

SDD  Contract  condition  end  is  close, SDD  Contract  condition  end  is  close 
Value„DATABASE(, "Variable", 

"User  Specified", "SDD  Contract  condition  end  is  close"): 

CCD, CCD  Value„DATABASE(, "Variable", "User  Specified", "CCD"): 

End  TD  contract, End  TD  contract  Value„DATABASE(, "Variable", "User  Specified", "End  TD 
contract"): 

ACAT  Level, ACAT  Level  Value„DATABASE(, "Variable", "User  Specified", "ACAT  Level"): 

Contract  Start  PreC, Contract  Start  PreC  Value„DATABASE(, "Variable", "User  Specified", "Contract 
Start  PreC"): 

MS  C  approval  attempt, MS  C  approval  attempt  Value„DATABASE(, "Variable", "User 
Specified", "MS  C  approval  attempt"): 

Kill  time  at  MS  B  decision, Kill  time  at  MS  B  decision  Value„DATABASE(, "Variable", "User 
Specified", 

"Kill  time  at  MS  B  decision"): 

PreC  Baseline, PreC  Baseline  Value„DATABASE(, "Variable", "User  Specified", "PreC  Baseline"): 

Kill  time  at  AFROC  indep  PreA, Kill  time  at  AFROC  indep  PreA  Value„DATABASE(, "Variable", "User 
Specified", 

"Kill  time  at  AFROC  indep  PreA"): 
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CDR,CDR  Value„DATABASE(, "Variable", "User  Specified", "CDR"): 

EOA  success, EOA  success  Value„DATABASE(, "Variable", "User  Specified", "EOA  success"): 

ICD,ICD  Value„DATABASE(, "Variable", "User  Specified", "ICD"): 

Kill  time  at  AFROC  indep  PreB,Kill  time  at  AFROC  indep  PreB  Value„DATABASE(, "Variable", "User 
Specified", 

"Kill  time  at  AFROC  indep  PreB"): 

Kill  time  at  AFROC  indep  preC,Kill  time  at  AFROC  indep  preC  Value„DATABASE(, "Variable", "User 
Specified", 

"Kill  time  at  AFROC  indep  preC"): 

Back  into  process  at  B  time, Back  into  process  at  B  time  Value„DATABASE(, "Variable", "User 
Specified", 

"Back  into  process  at  B  time"): 

MS  C  decision  time, MS  C  decision  time  Value„DATABASE(, "Variable", "User  Specified", "MS  C 
decision  time"): 

RequirementPathTrackPreB,RequirementPathTrackPreB  Value„DATABASE(, "Variable", "User 
Specified", 

"RequirementPathTrackPreB"): 

Kill  at  AFROC  joint  interest  PreA,  Kil I  at  AFROC  joint  interest  PreA 
Value„DATABASE(, "Variable", "User  Specified", 

"Kill  at  AFROC  joint  interest  PreA"): 

RequirementPathTrackPreC,RequirementPathTrackPreC  Value„DATABASE(, "Variable", "User 
Specified", 

"RequirementPathTrackPreC"): 

Program  Kill  Time  at  CDR, Program  Kill  Time  at  CDR  Value„DATABASE(, "Variable", "User 
Specified", 

"Program  Kill  Time  at  CDR"): 

contract  start, contract  start  Value„DATABASE(, "Variable", "User  Specified", "contract  start"): 
RequirementPathTrack,RequirementPathTrack  Value,,  DATABASE^  "Variable",  "User 
Specified'V'RequirementPathTrack"): 

CCD  Time, CCD  Time  Value„DATABASE(, "Variable", "User  Specified", "CCD  Time"): 

Acq  Plan  PreB,Acq  Plan  PreB  Value„DATABASE(, "Variable", "User  Specified", "Acq  Plan  PreB"); 

REPLICATE,  48500,„Yes,Yes„„24,Days,No,No,„No,No; 

ENTITIES:  Event  Happens  2,Picture.Telephone,0.0,0.0,0.0,0.0,0.0,0.0,AUTOSTATS(Yes„): 

Idea,  Picture.  Airplane, 0.0,l,0.0,0.0,0.0,0.0,AUTOSTATS(Yes„): 

ProgramreviewpreB, Picture. Red  Ball,0.0,0.0,0.0,0.0,0.0,0.0,AUTOSTATS(Yes„): 
ProgramreviewpreC,  PictureTel  low  Ball,0.0,0.0,0.0,0.0,0.0,0.0,AUTOSTATS(Yes„): 

Event  Happens, Picture. Letter, 0.0,0.0,0.0,0.0,0.0,0.0,AUTOSTATS(Yes„); 
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Enterprise  Acquisition  Process  Model 


Analyst: 

Filename: 

Report  Date: 
Replications: 

Start  Date/Time: 
Warm  Up  Period: 
Replication  Length: 
Base  Time  Units: 

Init  Stats  Between 
Replications: 

Init  Sytem  Between 
Replications: 

Model  Description: 


Robb  Wirthlin 

l:\Arena  model  iteration  Final  without  instrumentation. doe 

8/4/2009  1:08:28  PM 

48500 

2/25/2009  2:53:27  PM 
0.0 

Infinite 

Days 

True 

True 

None 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"ACAT  Level"  ID:  "Variable  4" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

ACAT  Level 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"AFROC  Count"  ID:  "Variable  5" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 
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I/O  Point 

No 

Name: 

AFROC  Count 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

AFROC  Count  PreB 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"AFROC  Count  PreB"  ID:  "Variable  20" 

Variable 

BasicProcess 

None 


Clear  Option:  System 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

AFROC  Count  PreC 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"AFROC  Count  PreC"  ID:  "Variable  43" 

Variable 

BasicProcess 

None 


Clear  Option:  System 


Data  Module  "Acq  Plan  PreB"  ID:  "Variable  36" 

Type:  Variable 
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BasicProcess 

None 


From  template: 
Module  Description: 
Operands: 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Acq  Plan  PreB 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Acq  Plan  PreC 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"Acq  Plan  PreC"  ID:  "Variable  56" 

Variable 

BasicProcess 

None 


Clear  Option:  System 


Columns: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

AcqPanelTry 

"AcqPanelTry"  ID:  "Variable  11" 

Variable 

BasicProcess 

None 


Clear  Option:  System 
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Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"AoA  flag"  ID:  "Variable  8" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

AoA  flag 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"AoA  killed"  ID:  "Variable  9" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

AoA  killed 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 


"Available"  ID:  "Calendar  State  1" 

Calendar  State 

BasicProcess 

None 
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Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Arena  Imported  Name: 

Color: 

51200 

FDM  Id: 

900000 

FDM  Name: 

Hatch  Color: 

0 

Hatch  Pattern: 

0 

Name: 

Available 

Usage  Type: 

Capacity 

Value: 

1 

"Back  into  process  at  A  time"  ID:  "Variable  83" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Back  into  process  at  A  time 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"Back  into  process  at  B  time"  ID:  "Variable  89" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Back  into  process  at  B  time 

Report  Statistics 

Yes 

Rows: 
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Usage: 


InputOutput 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Back  into  process  at  C  time"  ID:  "Variable  87" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Back  into  process  at  C  time 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Back  into  process  at  PreA"  ID:  "Variable  84" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Back  into  process  at  PreA 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Back  into  process  at  PreB"  ID:  "Variable  90" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 
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Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Back  into  process  at  PreB 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Back  into  process  at  PreC 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"Back  into  process  at  PreC"  ID:  "Variable  88" 

Variable 

BasicProcess 

None 


Clear  Option:  System 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Bring  the  processes  together  PreC. Queue"  ID:  "Queue  52" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

Bring  the  processes  together  PreC. Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module  "Bring  three  processes  together  PreB. Queue"  ID:  "Queue  22" 

Type:  Queue 

From  template:  BasicProcess 

Module  Description:  None 
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Operands: 


Attribute  Name: 

Attribute  1 

Name: 

Bring  three  processes  together  PreB. Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"CCD"  ID:  "Variable  21" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

CCD 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"CCD  Time"  ID:  "Variable  22" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

CCD  Time 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module  "CDR"  ID:  "Variable  59" 

Type:  Variable 
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From  template: 
Module  Description: 
Operands: 


Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

CDR 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

BasicProcess 

None 


Clear  Option:  System 


Columns: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

CDR  Rework  time 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"CDR  Rework  time"  ID:  "Variable  61" 

Variable 

BasicProcess 

None 


Clear  Option:  System 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"CPD"  ID:  "Variable  44" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

CPD 
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Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module  "CPD  Time"  ID:  "Variable  45" 

Type:  Variable 


From  template: 

BasicProcess 

Module  Description: 

None 

Operands: 

Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

CPD  Time 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 

'Complete  predecessor  activities  preA. Queue"  ID:  "Queue  7" 

Type:  Queue 

From  template: 

BasicProcess 

Module  Description: 

None 

Operands: 

Attribute  Name: 

Attribute  1 

Name: 

Complete  predecessor  activities  preA.Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Complete  predecessor  activities  preB. Queue"  ID:  "Queue  25" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

Complete  predecessor  activities  preB. Queue 

Report  Statistics 

Yes 

Shared 

No 
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Type: 


FIFO 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Complete  predecessor  activities  preC. Queue"  ID:  "Queue  55" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

Complete  predecessor  activities  preC. Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"CompletetimeofAoA"  ID:  "Variable  12" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

CompletetimeofAoA 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Contract  Start  PreC"  ID:  "Variable  50" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Contract  Start  PreC 
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Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Costing  Begin  PreB"  ID:  "Variable  37" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Costing  Begin  PreB 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Costing  Begin  PreC"  ID:  "Variable  57" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Costing  Begin  PreC 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 


"DRR  Rework"  ID:  "Variable  62" 

Variable 

BasicProcess 

None 
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Operands: 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

DRR  Rework 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"DRR  Success"  ID:  "Variable  66" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

DRR  Success 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"DRR  loop"  ID:  "Variable  67" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

DRR  loop 

Report  Statistics 

Yes 

Rows: 
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Usage: 


InputOutput 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Direct  entry  into  SDD  phase"  ID:  "Variable  113" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Direct  entry  into  SDD  phase 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Direct  entry  to  PreC  Phase"  ID:  "Variable  132" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Direct  entry  to  PreC  Phase 

Report  Statistics 

No 

Rows: 

Usage: 

InputOutput 

Data  Module 

'EOA  success"  ID: 

"Variable  35' 

Type:  Variable 

From  template: 

BasicProcess 

Module  Description: 

None 

Operands: 

Clear  Option: 

System 

Columns: 
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Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

EOA  success 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Early  Archive 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"Early  Archive"  ID:  "Variable  77" 

Variable 

BasicProcess 

None 


Clear  Option:  System 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

End  SDD  contract 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"End  SDD  contract"  ID:  "Variable  116" 

Variable 

BasicProcess 

None 


Clear  Option:  System 
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Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"End  TD  contract"  ID:  "Variable  114" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

End  TD  contract 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"End  at  COA  PreA"  ID:  "Variable  92" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

End  at  COA  PreA 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"Engineering  Development  model"  ID:  "Variable  76" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 
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I/O  Point 

No 

Name: 

Engineering  Development  model 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Event  Happens"  ID:  "Entity  7" 
Entity 

BasicProcess 

None 


Entity  Type: 

Event  Happens 

Holding  Cost  /  Hour: 

0.0 

Initial  Picture: 

Picture. Letter 

Non-Value  Added: 

0.0 

Other: 

0.0 

Report  Statistics 

Yes 

Transfer: 

0.0 

Value  Added: 

0.0 

Waiting: 

0.0 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Holding  Cost  /  Hour: 

0.0 

Initial  Picture: 

Picture.Telephone 

Non-Value  Added: 

0.0 

Other: 

0.0 

Report  Statistics 

Yes 

Transfer: 

0.0 

Value  Added: 

0.0 

Waiting: 

0.0 

"Event  Happens  2"  ID:  "Entity  11" 
Entity 

BasicProcess 

None 


Entity  Type: 


Event  Happens  2 


Data  Module  "Final  TD  contract  cost"  ID:  "Variable  115" 

Type:  Variable 
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From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Final  TD  contract  cost 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"Finish  in  Sustainment"  ID:  "Variable  82" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Finish  in  Sustainment 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"ICD"  ID:  "Variable?" 
Variable 
BasicProcess 
None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

ICD 
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Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"ICD  Time"  ID:  "Variable  6" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

ICD  Time 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Idea"  ID:  "Entity  2" 
Entity 

BasicProcess 

None 


Entity  Type: 

Idea 

Holding  Cost  /  Hour: 

0.0 

Initial  Picture: 

Picture. Airplane 

Non-Value  Added: 

0.0 

Other: 

0.0 

Report  Statistics 

Yes 

Transfer: 

0.0 

Value  Added: 

1 

Waiting: 

0.0 

Data  Module 
Type: 

From  template: 
Module  Description: 


"KPP  Development  signal  PreB"  ID:  "Variable  123" 

Variable 

BasicProcess 

None 
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Operands: 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

— 

I/O  Point 

No 

Name: 

KPP  Development  signal  PreB 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"KPPs  Ready  PreB"  ID:  "Variable  40" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

KPPs  Ready  PreB 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"KPPs  Ready  PreC"  ID:  "Variable  70" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

KPPs  Ready  PreC 

Report  Statistics 

Yes 

Rows: 
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Usage: 


InputOutput 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"KPPs  arrive  from  Requirements  PreC. Queue"  ID:  "Queue  59" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

KPPs  arrive  from  Requirements  PreC. Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"KPPs  arrive  from  Requirements. Queue"  ID:  "Queue  27" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

KPPs  arrive  from  Requirements. Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Kill  at  AFROC  joint  interest  PreA"  ID:  "Variable  107" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

— 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Kill  at  AFROC  joint  interest  PreA 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 
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Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Kill  at  Begin  of  requirements  swimlane  PreC"  ID:  "Variable  97" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Kill  at  Begin  of  requirements  swimlane  PreC 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"Kill  at  MS  A  decision  time"  ID:  "Variable  94" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Kill  at  MS  A  decision  time 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"Kill  at  begin  of  requirements  swimlane  PreB"  ID:  "Variable  95" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 
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I/O  Point 

No 

Name: 

Kill  at  begin  of  requirements  swimlane  PreB 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Kill  by  MDA  at  Concept  Decision  PreA 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"Kill  by  MDA  at  Concept  Decision  PreA"  ID:  "Variable  93" 

Variable 

BasicProcess 

None 


Clear  Option:  System 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Kill  time  at  AFROC  indep  PreA 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"Kill  time  at  AFROC  indep  PreA"  ID:  "Variable  101" 

Variable 

BasicProcess 

None 


Clear  Option:  System 


Data  Module  "Kill  time  at  AFROC  indep  PreB"  ID:  "Variable  102" 

Type:  Variable 
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From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Kill  time  at  AFROC  indep  PreB 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"Kill  time  at  AFROC  indep  preC"  ID:  "Variable  103" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Kill  time  at  AFROC  indep  preC 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"Kill  time  at  AFROC  joint  integ  PreA"  ID:  "Variable  104" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

— 

Data  Type: 

Real 

Description: 

— 

I/O  Point 

No 

Name: 

Kill  time  at  AFROC  joint  integ  PreA 
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Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Kill  time  at  AFROC  joint  integ  PreB"  ID:  "Variable  105" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

— 

I/O  Point 

No 

Name: 

Kill  time  at  AFROC  joint  integ  PreB 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Kill  time  at  AFROC  joint  integ  PreC"  ID:  "Variable  106" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Kill  time  at  AFROC  joint  integ  PreC 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 


"Kill  time  at  AFROC  joint  interest  PreC"  ID:  "Variable  109" 

Variable 

BasicProcess 

None 
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Operands: 


System 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Clear  Option: 


Columns: 

Data  Type: 

Real 

Description: 

| - 

I/O  Point 

No 

Name: 

Kill  time  at  AFROC  joint  interest  PreC 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"Kill  time  at  AFROC  joint  interest  preB"  ID:  "Variable  108" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Kill  time  at  AFROC  joint  interest  preB 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"Kill  time  at  MS  B  decision"  ID:  "Variable  96" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Kill  time  at  MS  B  decision 

Report  Statistics 

Yes 

Rows: 
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Usage: 


InputOutput 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Kill  time  at  MS  C  decision"  ID:  "Variable  98" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Kill  time  at  MS  C  decision 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"Killed  at  AoA"  ID:  "Variable  91" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Killed  at  AoA 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"MS  A  approval  attempt"  ID:  "Variable  14" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 
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Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

MS  A  approval  attempt 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"MS  A  decision  time"  ID:  "Variable  15" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

MS  A  decision  time 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"MS  B  approval  attempt"  ID:  "Variable  30" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

MS  B  approval  attempt 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 
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Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"MS  B  decision  time"  ID:  "Variable  29" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

MS  B  decision  time 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"MS  C  approval  attempt"  ID:  "Variable  73" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

MS  C  approval  attempt 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"MS  C  decision  time"  ID:  "Variable  72" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 
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I/O  Point 

No 

Name: 

MS  C  decision  time 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Needs  AOA  ICD  OK 

Report  Statistics 

No 

Rows: 

Usage: 

InputOutput 

"Needs  AOA  ICD  OK"  ID:  "Variable  133" 

Variable 

BasicProcess 

None 


Clear  Option:  System 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

PDR 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"PDR"  ID:  "Variable  58" 

Variable 

BasicProcess 

None 


Clear  Option:  System 


Columns: 


Data  Module  "PDR  Rework  time"  ID:  "Variable  60" 

Type:  Variable 
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From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

PDR  Rework  time 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"PDR  rework"  ID:  "Variable  118" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

PDR  rework 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"Pre  MS  B  contract  length"  ID:  "Variable  16" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Pre  MS  B  contract  length 
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Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"PreB  CCD  OK"  ID:  "Variable  131" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

PreB  CCD  OK 

Report  Statistics 

No 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"PreBpursuerequirements"  ID:  "Variable  17" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

PreBpursuerequirements 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 


"PreC  Baseline"  ID:  "Variable  71" 

Variable 

BasicProcess 

None 
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Operands: 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

PreC  Baseline 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"PreCpursuerequirements"  ID:  "Variable  41" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

PreCpursuerequirements 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Preferred  System  Concept"  ID:  "Variable  75" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Preferred  System  Concept 

Report  Statistics 

Yes 

Rows: 
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Usage: 


InputOutput 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Processes  come  together  PreB. Queue"  ID:  "Queue  20" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

Processes  come  together  PreB. Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Processes  come  together  PreC. Queue"  ID:  "Queue  51" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

Processes  come  together  PreC. Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Processes  come  together. Queue"  ID:  "Queue  5" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

Processes  come  together. Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 


"Program  Kill  Time  at  CDR"  ID:  "Variable  100" 

Variable 

BasicProcess 

None 
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Operands: 


System 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Clear  Option: 


Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Program  Kill  Time  at  CDR 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"Program  Kill  time  at  PDR"  ID:  "Variable  99" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Program  Kill  time  at  PDR 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"ProgramreviewpreB"  ID:  "Entity  5" 
Entity 

BasicProcess 

None 


Entity  Type: 

ProgramreviewpreB 

Holding  Cost  /  Hour: 

0.0 

Initial  Picture: 

Picture. Red  Ball 

Non-Value  Added: 

0.0 

Other: 

0.0 

Report  Statistics 

Yes 

Transfer: 

0.0 

Value  Added: 

0.0 
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Waiting: 


0.0 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"ProgramreviewpreC"  ID:  "Entity  8" 
Entity 

BasicProcess 

None 


Entity  Type: 

ProgramreviewpreC 

Holding  Cost  /  Hour: 

0.0 

Initial  Picture: 

Picture.Yellow  Ball 

Non-Value  Added: 

0.0 

Other: 

0.0 

Report  Statistics 

Yes 

Transfer: 

0.0 

Value  Added: 

0.0 

Waiting: 

0.0 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Receipt  of  approved  CCD. Queue"  ID:  "Queue  29" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

Receipt  of  approved  CCD. Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Receipt  of  approved  CPD. Queue"  ID:  "Queue  58" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

Receipt  of  approved  CPD. Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 
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Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Reject  in  formal  review  preA"  ID:  "Variable  81" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Reject  in  formal  review  preA 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"RequirementPathTrack"  ID:  "Variable  1" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

RequirementPathTrack 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"RequirementPathTrackPreB"  ID:  "Variable  19" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 
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I/O  Point 

No 

Name: 

RequirementPathTrackPreB 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"RequirementPathTrackPreC"  ID:  "Variable  42" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

RequirementPathTrackPreC 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Requires  AoA  but  not  ICD"  ID:  "Variable  112" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Requires  AoA  but  not  ICD 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module  "SDD  Contract  End  Date"  ID:  "Variable  49" 

Type:  Variable 
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From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

SDD  Contract  End  Date 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"SDD  Contract  Start"  ID:  "Variable  46" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

SDD  Contract  Start 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"SDD  Contract  condition  end  is  close"  ID:  "Variable  121" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

— 

Data  Type: 

Real 

Description: 

— 

I/O  Point 

No 

Name: 

SDD  Contract  condition  end  is  close 
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Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"SDD  Final  contract  cost"  ID:  "Variable  117" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

SDD  Final  contract  cost 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"SDD  Final  contract  length"  ID:  "Variable  119" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

SDD  Final  contract  length 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 


"SDD  contract  cost"  ID:  "Variable  47" 

Variable 

BasicProcess 

None 
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Operands: 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

SDD  contract  cost 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"SDD  contract  length"  ID:  "Variable  53" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

SDD  contract  length 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"SDD  original  contract  length"  ID:  "Variable  48" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

SDD  original  contract  length 

Report  Statistics 

Yes 

Rows: 
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Usage: 


InputOutput 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"SVR  rework"  ID:  "Variable  69" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

SVR  rework 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Schedule  quality"  ID:  "Variable  32" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Schedule  quality 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Schedule  quality  PreC"  ID:  "Variable  51" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 
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Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Schedule  quality  PreC 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Scope  of  Existing  CCD 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"Scope  of  Existing  CCD"  ID:  "Variable  111" 

Variable 

BasicProcess 

None 


Clear  Option:  System 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Selected  CoA  Kill  point 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"Selected  CoA  Kill  point"  ID:  "Variable  10" 

Variable 

BasicProcess 

None 


Clear  Option:  System 
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Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Start  AoA  flag"  ID:  "Variable  124" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Start  AoA  flag 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"StarttimeofAoA"  ID:  "Variable  13" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

StarttimeofAoA 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"System  Performance  Specification"  ID:  "Variable  74" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

i  | 

Data  Type: 

Real 

Description: 
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I/O  Point 

No 

Name: 

System  Performance  Specification 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

T  and  E  Start  PreB 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"T  and  E  Start  PreB"  ID:  "Variable  39" 

Variable 

BasicProcess 

None 


Clear  Option:  System 


Columns: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

TD  Contract  End  Date 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"TD  Contract  End  Date"  ID:  "Variable  128" 

Variable 

BasicProcess 

None 


Clear  Option:  System 


Data  Module  "TD  Contract  End  Date  Near"  ID:  "Variable  125" 

Type:  Variable 
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From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

TD  Contract  End  Date  Near 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"TD  Contract  Start"  ID:  "Variable  129" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

TD  Contract  Start 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"TD  Contract  length"  ID:  "Variable  127" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

TD  Contract  length 
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Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"TD  final  contract  length"  ID:  "Variable  126" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

TD  final  contract  length 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"TD  original  contract  length"  ID:  "Variable  130" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

TD  original  contract  length 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 


"TRR  Delay"  ID:  "Variable  63" 

Variable 

BasicProcess 

None 
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Operands: 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

TRR  Delay 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"TRR  loop"  ID:  "Variable  68" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

TRR  loop 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Trades  Delay"  ID:  "Variable  64" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Trades  Delay 

Report  Statistics 

Yes 

Rows: 
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Usage: 


InputOutput 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Color: 

200 

FDM  Id: 

900001 

FDM  Name: 

Flatch  Color: 

0 

Flatch  Pattern: 

0 

Name: 

Unavailable 

Usage  Type: 

Capacity 

Value: 

0 

"Unavailable"  ID:  "Calendar  State  2" 

Calendar  State 

BasicProcess 

None 

Arena  Imported  Name: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Wait  for  AoA  Start.Queue"  ID:  "Queue  61" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

Wait  for  AoA  Start.Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Wait  for  Baseline  set  PreC. Queue"  ID:  "Queue  54" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

Wait  for  Baseline  set  PreC. Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 
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Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Wait  for  CDR. Queue"  ID:  "Queue  49" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

Wait  for  CDR. Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Wait  for  EOA  completion. Queue"  ID:  "Queue  19" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

Wait  for  EOA  completion. Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Wait  for  PDR. Queue"  ID:  "Queue  47" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

Wait  for  PDR. Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Wait  for  RFP  Coord  Process  to  end. Queue"  ID:  "Queue  57" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

Wait  for  RFP  Coord  Process  to  end. Queue 
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Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Wait  for  T  and  E  Start.Queue"  ID:  "Queue  38" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

Wait  for  T  and  E  Start.Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Wait  for  T  and  E  signal. Queue"  ID:  "Queue  31" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

Wait  for  T  and  E  signal. Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Wait  for  contract  complete. Queue"  ID:  "Queue  36" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

Wait  for  contract  complete. Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 


"Wait  for  signal  for  Costing  and  Acquisition  Planning  activities  PreB. Queue" 
ID:  "Queue  40" 
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Type: 

From  template: 
Module  Description: 
Operands: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Queue 

BasicProcess 

None 


Attribute 

Name: 

Attribute  1 

Name: 

Wait  for  signal  for  Costing  and  Acquisition  Planning  activities 
PreB. Queue 

Report 

Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

"Wait  for  signal  for  Costing  and  Acquisition  Planning  activities  PreC. Queue" 

ID:  "Queue  46" 

Queue 

BasicProcess 

None 

Attribute 

Name: 

Attribute  1 

Name: 

Wait  for  signal  for  Costing  and  Acquisition  Planning  activities 
PreC. Queue 

Report 

Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Wait  for  successful  Design  Readiness  Review  Indep  PreC. Queue"  ID:  "Queue 
43" 

Queue 

BasicProcess 

None 


Attribute 

Name: 

Attribute  1 

Name: 

Wait  for  successful  Design  Readiness  Review  Indep 

PreC. Queue 

Report 

Statistics 

Yes 

Shared 

No 

Type: 

FIFO 
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Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Wait  for  successful  Design  Readiness  Review  Interest  PreC. Queue"  ID: 
"Queue  44" 

Queue 

BasicProcess 

None 


Attribute 

Name: 

Attribute  1 

Name: 

Wait  for  successful  Design  Readiness  Review  Interest 

PreC. Queue 

Report 

Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Wait  for  successful  Design  Readiness  Review  Joint  PreC. Queue"  ID:  "Queue 
45" 

Queue 

BasicProcess 

None 


Attribute 

Name: 

Attribute  1 

Name: 

Wait  for  successful  Design  Readiness  Review  Joint 

PreC. Queue 

Report 

Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"Wait  until  both  complete  preA.Queue"  ID:  "Queue  3" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

Wait  until  both  complete  preA.Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 
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Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

Waiting  Period  End 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"Waiting  Period  End"  ID:  "Variable  78" 

Variable 

BasicProcess 

None 


Clear  Option:  System 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

contract  cost 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"contract  cost"  ID:  "Variable  31" 

Variable 

BasicProcess 

None 


Clear  Option:  System 


Columns: 


Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"contract  start"  ID:  "Variable  33" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 
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Description: 

I/O  Point 

No 

Name: 

contract  start 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"contractor  loop"  ID:  "Variable  27" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

contractor  loop 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"contractor  loop  PreC"  ID:  "Variable  55" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

contractor  loop  PreC 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module  "for  Affordability  Assessment  PreB. Queue"  ID:  "Queue  24" 
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Queue 

BasicProcess 

None 


Type: 

From  template: 
Module  Description: 
Operands: 


Attribute  Name: 

Attribute  1 

Name: 

for  Affordability  Assessment  PreB. Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"for  Affordability  Assessment  PreC.Queue"  ID:  "Queue  50" 

Queue 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Name: 

for  Affordability  Assessment  PreC.Queue 

Report  Statistics 

Yes 

Shared 

No 

Type: 

FIFO 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

funding  quality 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

"funding  quality"  ID:  "Variable  26" 

Variable 

BasicProcess 

None 


Clear  Option:  System 


Data  Module 
Type: 

From  template: 


"funding  quality  PreC"  ID:  "Variable  52" 

Variable 

BasicProcess 
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Module  Description: 
Operands: 


None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

funding  quality  PreC 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"testinglength"  ID:  "Variable  28" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

testinglength 

Report  Statistics 

Yes 

Rows: 

Usage: 

InputOutput 

Data  Module 
Type: 

From  template: 
Module  Description: 
Operands: 


"trade  counter"  ID:  "Variable  65" 

Variable 

BasicProcess 

None 


Clear  Option: 

System 

Columns: 

Data  Type: 

Real 

Description: 

I/O  Point 

No 

Name: 

trade  counter 

Report  Statistics 

Yes 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Rows: 

Usage: 

InputOutput 

"ACAT  1  Preparation  for  Acquisition  Panels  preA"  ID:  "Process  76" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

40 

Name: 

ACAT  1  Preparation  for  Acquisition  Panels  preA 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

56 

"ACAT  1  Preparation  for  Acquisition  Panels  preB"  ID:  "Process  143" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

40 

Name: 

ACAT  1  Preparation  for  Acquisition  Panels  preB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 
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Units: 

Days 

Value 

56 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


If: 

Entity  Type 

Is: 

>= 

Name: 

ACAT  1  funding 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

70 

Row: 

1 

Type: 

With 

Value: 

1 

"ACAT  1  funding"  ID:  "Decide  49" 

Decide 

BasicProcess 

None 


Column: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"ACAT  I  Contract  Length"  ID:  "Assign  39" 

Assign 

BasicProcess 

None 


Name: 


ACAT  I  Contract  Length 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"ACAT  I  Contract  Length  PreC"  ID:  "Assign  91" 

Assign 

BasicProcess 

None 


Name: 


ACAT  I  Contract  Length  PreC 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"ACAT  I  prepare  for  Acquisition  panels"  ID:  "Process  68" 

Process 

BasicProcess 

None 


Action: 


D 
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Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

40 

Name: 

ACAT  1  prepare  for  Acquisition  panels 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

55 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"ACAT  I  time  delay"  ID:  "Process  66" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

180 

Minimum: 

30 

Name: 

ACAT  1  time  delay 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

45 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"ACAT  I  time  delay  PreB"  ID:  "Process  133" 

Process 

BasicProcess 

None 


Action: 


D 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

180 

Minimum: 

30 

Name: 

ACAT  1  time  delay  PreB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

120 

"ACAT  I  time  delay  PreC"  ID:  "Process  221" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

180 

Minimum: 

30 

Name: 

ACAT  1  time  delay  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

120 

"ACAT  II  Contract  Length"  ID:  "Assign  40" 

Assign 

BasicProcess 

None 


Name: 


ACAT  II  Contract  Length 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"ACAT  II  Contract  Length  PreC"  ID:  "Assign  92" 
Assign 

BasicProcess 

None 


Name: 


ACAT  II  Contract  Length  PreC 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"ACAT  II  or  ACAT  III  funding"  ID:  "Decide  50" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

ACAT  II  or  ACAT  III  funding 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"ACAT  II  or  ACAT  III  time  delay"  ID:  "Process  67" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

240 

Minimum: 

90 

Name: 

ACAT  II  or  ACAT  III  time  delay 

Priority: 

2 

Report  Statistics 

No 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

150 

"ACAT  II  or  ACAT  III  time  delay  PreB"  ID:  "Process  134" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

270 

Minimum: 

90 

Name: 

ACAT  II  or  ACAT  III  time  delay  PreB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

225 

"ACAT  II  or  ACAT  III  time  delay  PreC"  ID:  "Process  222" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

270 

Minimum: 

90 

Name: 

ACAT  II  or  ACAT  III  time  delay  PreC 

Priority: 

2 

Report  Statistics 

No 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

225 

"ACAT  II  or  III  Preparation  for  Acquisition  Panels"  ID:  "Process  77" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

30 

Minimum: 

15 

Name: 

ACAT  II  or  III  Preparation  for  Acquisition  Panels 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

25 

"ACAT  II  or  III  Preparation  for  Acquisition  Panels  preB"  ID:  "Process  144" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

30 

Minimum: 

15 

Name: 

ACAT  II  or  III  Preparation  for  Acquisition  Panels  preB 

Priority: 

2 

Report  Statistics 

No 
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Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

25 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

35 

Minimum: 

15 

Name: 

ACAT  II  or  III  Prepare  for  Acquisition  Panels  preA 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

30 

"ACAT  II  or  III  Prepare  for  Acquisition  Panels  preA"  ID:  "Process  69" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"ACAT  III  Contract  Length"  ID:  "Assign  41" 

Assign 

BasicProcess 

None 


Name: 


ACAT  III  Contract  Length 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"ACAT  III  Contract  Length  PreC"  ID:  "Assign  93" 
Assign 

BasicProcess 

None 


Name: 


ACAT  III  Contract  Length  PreC 


Module 


"ACAT  level  check  for  Acquisition  swimlane  preA"  ID:  "Decide  57" 
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Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

ACAT  level  check  for  Acquisition  swimlane  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

ACAT  Level 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

"ACAT  level  check  preA"  ID:  "Decide  60" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

ACAT  level  check  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

ACAT  Level 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

"ACAT  level  check  preB"  ID:  "Decide  111" 

Decide 

BasicProcess 

None 


Column: 


1 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


If: 

Variable 

Is: 

== 

Name: 

ACAT  level  check  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

ACAT  Level 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

"ACAT  level  preA"  ID:  "Decide  56" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

ACAT  level  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

ACAT  Level 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

"ACAT  level  preB"  ID:  "Decide  107" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

ACAT  level  preB 

Named: 

Attribute  1 
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Named: 

Entity  1 

Named: 

ACAT  Level 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"ACAT  level  preC"  ID:  "Decide  180" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

ACAT  level  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

ACAT  Level 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Acquisition  Panels"  ID:  "Process  78" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

35 

Minimum: 

15 

Name: 

Acquisition  Panels 

Priority: 

2 

Report  Statistics 

No 

651 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

30 

"Acquisition  Panels  PreB"  ID:  "Process  145" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

35 

Minimum: 

15 

Name: 

Acquisition  Panels  PreB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

30 

"Acquisition  Panels  PreC"  ID:  "Process  228" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

35 

Minimum: 

15 

Name: 

Acquisition  Panels  PreC 

Priority: 

2 

Report  Statistics 

No 

652 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

30 

"Acquisition  Panels  preparation  PreC"  ID:  "Process  271" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Expression 

Expression: 

ACAT  level==l*TRIA(40,56,60)+ACAT  level==2*TRIA(15,25,30) 

+  ACAT  level==3*TRIA(15,25,30) 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

Acquisition  Panels  preparation  PreC 

Priority: 

2 

Report 

Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

1 

"Acquisition  Planning  Activities  PreB"  ID:  "Process  157" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

Acquisition  Planning  Activities  PreB 
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Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Submodel 

Units: 

Hours 

Value 

1 

Submodel  for  Module  Acquisition  Planning  Activities  PreB 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

250 

Minimum: 

120 

Name: 

ACAT  1  Acquisition  Planning  PreB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

240 

"ACAT  I  Acquisition  Planning  PreB"  ID:  "Process  158" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"ACAT  II  Or  III  Acquisition  Planning  PreB"  ID:  "Process  159" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Maximum: 

250 

Minimum: 

120 

Name: 

ACAT  II  Or  III  Acquisition  Planning  PreB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

185 

"Acq  planning  activities  depend  upon  ACAT  level  preB"  ID:  "Decide  130" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Acq  planning  activities  depend  upon  ACAT  level  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

ACAT  Level 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

"Acquisition  Planning  Activities  PreC"  ID:  "Process  234" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

1.5 

Minimum: 

.5 
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Name: 

Acquisition  Planning  Activities  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Submodel 

Units: 

Hours 

Value 

1 

Submodel  for  Module  Acquisition  Planning  Activities  PreC 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

250 

Minimum: 

120 

Name: 

ACAT  1  Acquisition  Planning  PreC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

240 

"ACAT  I  Acquisition  Planning  PreC"  ID:  "Process  235" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"ACAT  II  Or  III  Acquisition  Planning  PreC"  ID:  "Process  236" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Expression: 

1 

Maximum: 

250 

Minimum: 

120 

Name: 

ACAT  II  Or  III  Acquisition  Planning  PreC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

185 

"Acq  planning  activities  depend  upon  ACAT  level  preC"  ID:  "Decide  193" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Acq  planning  activities  depend  upon  ACAT  level  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

ACAT  Level 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

"Acquisition  panels  preA"  ID:  "Process  70" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

35 
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Minimum: 

15 

Name: 

Acquisition  panels  preA 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

30 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Add  counter  through  feedback  path"  ID:  "Assign  1" 

Assign 

BasicProcess 

None 


Name: 


Add  counter  through  feedback  path 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Add  counter  through  feedback  path  PreB"  ID:  "Assign  25" 
Assign 

BasicProcess 

None 


Name: 


Add  counter  through  feedback  path  PreB 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Add  counter  through  feedback  path  PreC"  ID:  "Assign  81" 

Assign 

BasicProcess 

None 


Name: 


Add  counter  through  feedback  path  PreC 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Additional  Adjustments"  ID:  "Decide  142" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Additional  Adjustments 

Named: 

Attribute  1 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

50 

Row: 

1 

Type: 

With 

Value: 

1 

"Affordability  Assessment  PreB"  ID:  "Process  175" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

180 

Minimum: 

120 

Name: 

Affordability  Assessment  PreB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

160 

"Affordability  Assessment  PreC"  ID:  "Process  249" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

180 

Minimum: 

120 

Name: 

Affordability  Assessment  PreC 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

160 

"Analysis"  ID:  "Process  62" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

180 

Minimum: 

2 

Name: 

Analysis 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

7 

"Analysis  of  Alternatives"  ID:  "Process  61" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

730 

Minimum: 

270 

Name: 

Analysis  of  Alternatives 
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Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

600 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Approve  Selected  CoA"  ID:  "Decide  54" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Approve  Selected  CoA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Archive  for  rejected  ideas  in  formal  review"  ID:  "Dispose  32" 

Dispose 

BasicProcess 

None 


Name: 

Archive  for  rejected  ideas  in  formal  review 

Record  Entity  Statistics 

No 

Module 

'Assembly"  ID: 

"Process  264" 

Type: 

Process 

From  template: 

BasicProcess 

Module  Description: 

None 

Operands: 

Action: 

D 

Allocation: 

VA 
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Delay  Type: 

Expression 

Expression: 

TRIA(.06*SDD  original  contract  length,  ,1*SDD  original 

contract  length,  ,11*SDD  original  contract  length) 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

Assembly 

Priority: 

2 

Report 

Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

1 

Module 

Type: 

From  template: 

Module  Description: 
Operands: 

"Assign  Beginning  simulation  time"  ID:  "Assign  147" 

Assign 

BasicProcess 

None 

Name:  Assign  Beginning  simulation  time 

Module 

"Assign  CDR  Rework  time"  ID:  "Assign  144" 

Type: 

Assign 

From  template: 

BasicProcess 

Module  Description: 

None 

Operands: 

Name:  Assign  CDR  Rework  time 

Module 

"Assign  CDR1  Cost  and  Schedule  Penalty"  ID:  "Assign  115" 

Type: 

Assign 

From  template: 

BasicProcess 

Module  Description: 

None 

Operands: 

Name:  Assign  CDR1  Cost  and  Schedule  Penalty 

Module 

Type: 

From  template: 
Module  Description: 


"Assign  CDR2  Cost  and  Schedule  Penalty"  ID:  "Assign  116" 

Assign 

BasicProcess 

None 
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Operands: 

Name:  Assign  CDR2  Cost  and  Schedule  Penalty 

Module 

"Assign  KPP  Development  complete  PreB"  ID:  "Assign  146" 

Type: 

Assign 

From  template: 

BasicProcess 

Module  Description: 

None 

Operands: 

Name:  Assign  KPP  Development  complete  PreB 

Module 

"Assign  PDR1  Cost  and  Schedule  Penalty"  ID:  "Assign  112" 

Type: 

Assign 

From  template: 

BasicProcess 

Module  Description: 

None 

Operands: 

Name:  Assign  PDR1  Cost  and  Schedule  Penalty 

Module 

"Assign  PDR1  rework  time"  ID:  "Assign  142" 

Type: 

Assign 

From  template: 

BasicProcess 

Module  Description: 

None 

Operands: 

Name:  Assign  PDR1  rework  time 

Module 

"Assign  PDR2  Cost  and  Schedule  Penalty"  ID:  "Assign  113" 

Type: 

Assign 

From  template: 

BasicProcess 

Module  Description: 

None 

Operands: 

Name:  Assign  PDR2  Cost  and  Schedule  Penalty 

Module 

"Assign  PDR2  rework"  ID:  "Assign  143" 

Type: 

Assign 

From  template: 

BasicProcess 

Module  Description: 

None 

Operands: 

Name:  Assign  PDR2  rework 

Module 

"Assign  PDR3  Cost  and  Schedule  Penalty"  ID:  "Assign  114" 

Type: 

Assign 

From  template: 

BasicProcess 

Module  Description: 

None 
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Operands: 


Name: 


Assign  PDR3  Cost  and  Schedule  Penalty 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Assign  Program  Kill  at  CDR"  ID:  "Assign  136" 

Assign 

BasicProcess 

None 


Name: 


Assign  Program  Kill  at  CDR 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Assign  Set  close  to  end  SDD  contract  condition"  ID:  "Assign  145" 

Assign 

BasicProcess 

None 


Name: 


Assign  Set  close  to  end  SDD  contract  condition 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Assign  cost  penalty  for  DRR  rework"  ID:  "Assign  119" 

Assign 

BasicProcess 

None 


Name: 


Assign  cost  penalty  for  DRR  rework 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Assign  counter  to  MDA  loop"  ID:  "Assign  21" 

Assign 

BasicProcess 

None 


Name: 


Assign  counter  to  MDA  loop 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Assign  counter  to  MDA  loop  preB"  ID:  "Assign  37" 
Assign 

BasicProcess 

None 


Name: 


Assign  counter  to  MDA  loop  preB 


Module  "Assign  counter  to  MDA  loop  preC"  ID:  "Assign  89" 

Type:  Assign 

From  template:  BasicProcess 

Module  Description:  None 
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Operands: 


Name: 


Assign  counter  to  MDA  loop  preC 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Assign  final  SDD  cost"  ID:  "Assign  141" 

Assign 

BasicProcess 

None 


Name: 


Assign  final  SDD  cost 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Assign  final  contract  cost"  ID:  "Assign  140" 

Assign 

BasicProcess 

None 


Name: 


Assign  final  contract  cost 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Assign  program  kill  at  PDR"  ID:  "Assign  135" 

Assign 

BasicProcess 

None 


Name: 


Assign  program  kill  at  PDR 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


If: 

Expression 

Is: 

<= 

Name: 

Begin  Testing  ACAT  II  or  III  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Technology  Development  Contract  length 

Percent 

True 

50 

Row: 

1 

Type: 

If 

Value: 

TNOW.GE.((0.85*TD  original  contract  length  )  +  TD  Contract 

"Begin  Testing  ACAT  II  or  III  PreB"  ID:  "Decide  135" 

Decide 

BasicProcess 

None 


Column: 


665 


Start) 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Begin  Testing  PreB"  ID:  "Decide  133" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Expression 

Is: 

>= 

Name: 

Begin  Testing  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Technology  Development  Contract  length 

Percent 

True 

50 

Row: 

1 

Type: 

If 

Value: 

TNOW.GE.  ( (0.75*TD  original  contract  length  )  +TD  Contract 
Start ) 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Bring  the  processes  together  PreC"  ID:  "Batch  17" 
Batch 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Batch  Size: 

2 

Name: 

Bring  the  processes  together  PreC 

Representative  Entity  Type: 

Rule: 

Any  Entity 

Save  Criterion: 

Last 

Type: 

Permanent 

Module 

Type: 

From  template: 
Module  Description: 


"Bring  three  processes  together  PreB"  ID:  "Batch  12" 
Batch 

BasicProcess 

None 
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Operands: 


Attribute  Name: 

Attribute  1 

Batch  Size: 

3 

Name: 

Bring  three  processes  together  PreB 

Representative  Entity  Type: 

Rule: 

Any  Entity 

Save  Criterion: 

Last 

Type: 

Permanent 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"CDR  2"  ID:  "Decide  216" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

CDR  2 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

90 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"CDR  3"  ID:  "Decide  217" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

CDR  3 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Row: 

1 

Type: 

With 

Value: 

1 

"CDR  Rework  PreC"  ID:  "Process  257" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Expression 

Expression: 

CDR  Rework  time 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

CDR  Rework  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

1 

"CDR  delay  2  PreC"  ID:  "Process  258" 


Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Expression 

Expression: 

,5*CDR  Rework  time 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

CDR  delay  2  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 
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Type: 

Standard 

Units: 

Days 

Value 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"CDR  success??"  ID:  "Decide  215" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

CDR  success?? 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

70 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Change  CDR  variable"  ID:  "Assign  111" 

Assign 

BasicProcess 

None 


Name: 


Change  CDR  variable 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

15 

"Change  Contract  or  Rescope  contract  PreB"  ID:  "Process  156" 

Process 

BasicProcess 

None 


Action: 


D 


669 


Name: 

Change  Contract  or  Rescope  contract  PreB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

20 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

15 

Name: 

Change  Contract  or  Rescope  contract  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

20 

"Change  Contract  or  Rescope  contract  PreC"  ID:  "Process  233" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Change  PDR  variable"  ID:  "Assign  110" 

Assign 

BasicProcess 

None 


Name: 


Change  PDR  variable 


Module 

Type: 

From  template: 
Module  Description: 


"Check  Condition"  ID:  "Decide  14" 

Decide 

BasicProcess 

None 
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Operands: 


Column: 

1 

If: 

Variable 

Is: 

>= 

Name: 

Check  Condition 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

RequirementPathT  rack 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Check  Condition  PreB"  ID:  "Decide  72" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

>= 

Name: 

Check  Condition  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

RequirementPathT  rack 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Check  Condition  PreC"  ID:  "Decide  152" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

>= 

Name: 

Check  Condition  PreC 

671 


Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

RequirementPathT  rack 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Check  DRR  looping  condition"  ID:  "Decide  223" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Check  DRR  looping  condition 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

DRR  loop 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

0 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Check  TRR  looping  condition"  ID:  "Decide  224" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Check  TRR  looping  condition 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

TRR  loop 

Percent  True 

50 

672 


Row: 

1 

Type: 

If 

Value: 

0 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Check  for  ACAT  level  for  potential  AoA"  ID:  "Decide  48" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Check  for  ACAT  level  for  potential  AoA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

ACAT  Level 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


If: 

Variable 

Is: 

== 

Name: 

Check  for  ACAT  level  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

ACAT  Level 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

"Check  for  ACAT  level  preA"  ID:  "Decide  21" 

Decide 

BasicProcess 

None 


Column: 


673 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 


"Check  for  AoA"  ID:  "Decide  52" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Check  for  AoA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

50 

Row: 

1 

Type: 

Nlf 

Value: 

1 

"Check  for  previous  MDA  decision  attempt  preA"  ID:  "Decide  62" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Check  for  previous  MDA  decision  attempt  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

MS  A  approval  attempt 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

"Check  for  previous  MDA  decision  attempt  preB"  ID:  "Decide  113" 

Decide 

BasicProcess 

None 


674 


Operands: 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Check  for  previous  MDA  decision  attempt  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

MS  B  approval  attempt 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Check  for  previous  MDA  decision  attempt  preC"  ID:  "Decide  183" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Check  for  previous  MDA  decision  attempt  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

MS  C  approval  attempt 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Check  for  previous  path"  ID:  "Decide  59" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Check  for  previous  path 
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Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

AcqPanelTry 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Check  looping  condition"  ID:  "Decide  222" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Check  looping  condition 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

trade  counter 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

0 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Check  on  conditions"  ID:  "Decide  65" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Check  on  conditions 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

PreBpursuerequirements 

Percent  True 

50 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Row: 

1 

Type: 

If 

Value: 

1 

"Check  on  conditions  PreC"  ID:  "Decide  147" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Check  on  conditions  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

PreCpursuerequirements 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

"Choose  and  recommend  a  selected  CoA"  ID:  "Process  64" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

90 

Minimum: 

30 

Name: 

Choose  and  recommend  a  selected  CoA 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 
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Value 


60 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Combined  Testing"  ID:  "Process  269" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Expression 

Expression: 

TRIA(.07*SDD  original  contract  length,  0.1*SDD  original 

contract  length,  0.11*SDD  original  contract  length) 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

Combined  Testing 

Priority: 

2 

Report 

Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Complete  predecessor  activities  preA"  ID:  "Batch  4" 
Batch 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Batch  Size: 

3 

Name: 

Complete  predecessor  activities  preA 

Representative  Entity  Type: 

Rule: 

Any  Entity 

Save  Criterion: 

Last 

Type: 

Permanent 

"Complete  predecessor  activities  preB"  ID:  "Batch  8" 
Batch 

BasicProcess 


Module 

Type: 

From  template: 
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None 


Module  Description: 
Operands: 


Attribute  Name: 

Attribute  1 

Batch  Size: 

2 

Name: 

Complete  predecessor  activities  preB 

Representative  Entity  Type: 

Rule: 

Any  Entity 

Save  Criterion: 

Last 

Type: 

Permanent 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Batch  Size: 

2 

Name: 

Complete  predecessor  activities  preC 

Representative  Entity  Type: 

Rule: 

Any  Entity 

Save  Criterion: 

Last 

Type: 

Permanent 

"Complete  predecessor  activities  preC"  ID:  "Batch  16" 
Batch 

BasicProcess 

None 


Attribute  Name: 


Attribute  1 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Completion  of  contract  PreB"  ID:  "Dispose  28" 

Dispose 

BasicProcess 

None 


Name: 

Completion  of  contract  PreB 

Record  Entity  Statistics 

No 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Completion  of  contract  PreC"  ID:  "Dispose  43" 

Dispose 

BasicProcess 

None 


Name: 

Completion  of  contract  PreC 

Record  Entity  Statistics 

No 

Module  "Concept  Decision  and  ADM"  ID:  "Decide  58" 
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Decide 

BasicProcess 

None 


Type: 

From  template: 
Module  Description: 
Operands: 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Concept  Decision  and  ADM 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Conduct  AoA"  ID:  "Decide  53" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Conduct  AoA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Continue  until  completion  and  End  of  process"  ID:  "Dispose  2" 

Dispose 

BasicProcess 

None 


Name: 


Continue  until  completion  and  End  of  process 
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Record  Entity  Statistics 


No 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Continute  other  Acquisition  Swimlane  activities  preA"  ID:  "Separate  3" 

Separate 

BasicProcess 

None 


#  of  Duplicates: 

1 

Member  Attributes: 

Retain  Original  Entity  Values 

Name: 

Continute  other  Acquisition  Swimlane  activities 
preA 

Percent  Cost  to 

Duplicates 

0 

Type: 

Duplicate 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

45 

Minimum: 

30 

Name: 

Contract  Startup  PreB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

42 

"Contract  Startup  PreB"  ID:  "Process  160" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 


"Contract  Startup  PreC"  ID:  "Process  237" 

Process 

BasicProcess 

None 
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Operands: 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

45 

Minimum: 

30 

Name: 

Contract  Startup  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

42 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Contract  complete  PreB"  ID:  "Decide  138" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Expression 

Is: 

<= 

Name: 

Contract  complete  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Technology  Development  Contract  length 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

TNOW.GE.TD  Contract  End  Date  |  |  End  TD  contract 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Contract  complete  PreC"  ID:  "Decide  200" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Expression 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Is: 

<= 

Name: 

Contract  complete  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Technology  Development  Contract  length 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

TNOW.GE.SDD  Contract  End  Date  |  |  End  SDD  contract 

"Contract  started  PreB"  ID:  "Decide  144" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Contract  started  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

contract  start 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

"Contract  started  PreC"  ID:  "Decide  205" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Contract  started  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Named: 

Contract  Start  PreC 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

"Contractor  cost  estimate  PreB"  ID:  "Process  173" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

90 

Minimum: 

45 

Name: 

Contractor  cost  estimate  PreB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

50 

"Contractor  cost  estimate  PreC"  ID:  "Process  247" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

90 

Minimum: 

45 

Name: 

Contractor  cost  estimate  PreC 

Priority: 

2 
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Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

50 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Contractor  loop  counter  preB"  ID:  "Assign  49" 

Assign 

BasicProcess 

None 


Name: 


Contractor  loop  counter  preB 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


If: 

Expression 

Is: 

>= 

Name: 

Critical  Design  Review 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

TNOW.GE.  ( (SDD  contract  length*0.45)  +  SDD  Contract  Start ) 

"Critical  Design  Review"  ID:  "Decide  209" 

Decide 

BasicProcess 

None 


Column: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"DRR  rework  and  delay"  ID:  "Process  262" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Expression 

Expression: 

DRR  Rework 
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Maximum: 

180 

Minimum: 

30 

Name: 

DRR  rework  and  delay 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

150 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Decision  to  Repursue"  ID:  "Decide  13" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Decision  to  Repursue 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

85 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Decision  to  Repursue  PreB"  ID:  "Decide  71" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Decision  to  Repursue  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

686 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Named: 

Variable  1 

Percent  True 

85 

Row: 

1 

Type: 

With 

Value: 

1 

"Decision  to  Repursue  PreC"  ID:  "Decide  151" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Decision  to  Repursue  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

85 

Row: 

1 

Type: 

With 

Value: 

1 

"Decision  to  pursue  requirements"  ID:  "Decide  8" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Decision  to  pursue  requirements 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

25 

Row: 

1 

Type: 

With 
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Value: 


1 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Decision  to  pursue  requirements  PreB"  ID:  "Decide  64" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Decision  to  pursue  requirements  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

98 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Decision  to  pursue  requirements  PreC"  ID:  "Decide  146" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Decision  to  pursue  requirements  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

98 

Row: 

1 

Type: 

With 

Value: 

1 

Module  "Declare  Acq  Planning  and  Costing  to  Begin"  ID:  "Assign  73" 

Type:  Assign 
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From  template: 
Module  Description: 
Operands: 


BasicProcess 

None 


Name: 


Declare  Acq  Planning  and  Costing  to  Begin 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Declare  Acq  Planning  and  Costing  to  Begin  PreC"  ID:  "Assign  108" 

Assign 

BasicProcess 

None 


Name:  Declare  Acq  Planning  and  Costing  to  Begin  PreC 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Declare  EOA  success"  ID:  "Assign  72" 
Assign 

BasicProcess 

None 


Name: 


Declare  EOA  success 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Declare  KPPs  ready  for  Acquisition  PreB"  ID:  "Assign  76" 

Assign 

BasicProcess 

None 


Name: 


Declare  KPPs  ready  for  Acquisition  PreB 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Declare  start  of  T  and  E  PreB"  ID:  "Assign  75" 

Assign 

BasicProcess 

None 


Name: 


Declare  start  of  T  and  E  PreB 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Delay  for  Protest  review  PreB"  ID:  "Process  148" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Maximum: 

60 

Minimum: 

30 

Name: 

Delay  for  Protest  review  PreB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

50 

"Delay  for  Protest  review  PreC"  ID:  "Process  231" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

30 

Name: 

Delay  for  Protest  review  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

50 

"Delay  to  Align  Funds  PreC"  ID:  "Process  252" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Maximum: 

75 

Minimum: 

30 

Name: 

Delay  to  Align  Funds  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

35 

"Delay  to  repeat  required  steps  PreB"  ID:  "Process  273" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

180 

Minimum: 

60 

Name: 

Delay  to  repeat  required  steps  PreB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

120 

"Delay  to  repeat  required  steps  PreC"  ID:  "Process  272" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 
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Maximum: 

180 

Minimum: 

60 

Name: 

Delay  to  repeat  required  steps  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

120 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Design  Readiness  Review"  ID:  "Decide  219" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Design  Readiness  Review 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

90 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Determine  DRR  Rework"  ID:  "Assign  118" 

Assign 

BasicProcess 

None 


Name: 


Determine  DRR  Rework 


Module 

Type: 

From  template: 
Module  Description: 


"Determine  TRR  delay"  ID:  "Assign  120" 

Assign 

BasicProcess 

None 
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Operands: 


Name: 


Determine  TRR  delay 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Determine  contract  end  date"  ID:  "Assign  71" 

Assign 

BasicProcess 

None 


Name: 


Determine  contract  end  date 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Determine  contract  end  date  PreC"  ID:  "Assign  106" 

Assign 

BasicProcess 

None 


Name: 


Determine  contract  end  date  PreC 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Determine  cost  and  schedule  penalties  for  TRR  delays"  ID:  "Assign  121" 

Assign 

BasicProcess 

None 


Name: 


Determine  cost  and  schedule  penalties  for  TRR  delays 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Determine  cost  and  schedule  penalties  for  trades  delays"  ID:  "Assign  123" 

Assign 

BasicProcess 

None 


Name: 


Determine  cost  and  schedule  penalties  for  trades  delays 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


If: 

Entity  Type 

Is: 

>= 

Name: 

Determine  document  approval  path  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

"Determine  document  approval  path  preA"  ID:  "Decide  22" 

Decide 

BasicProcess 

None 


Column: 


693 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Named: 

Variable  1 

Percent  True 

50 

Row: 

1 

Type: 

Nlf 

Value: 

1 

"Determine  document  approval  path  preB"  ID:  "Decide  74" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Determine  document  approval  path  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

50 

Row: 

1 

Type: 

Nlf 

Value: 

1 

"Determine  document  approval  path  preC"  ID:  "Decide  153" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Determine  document  approval  path  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

50 

Row: 

1 

Type: 

Nlf 
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Value: 


1 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Determine  final  SDD  cost"  ID:  "Decide  226" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Determine  final  SDD  cost 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

End  SDD  contract 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

0 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


If: 

Entity  Type 

Is: 

>= 

Name: 

Determine  path  for  process  flow  Scope  Growth  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

80 

Row: 

1 

Type: 

With 

Value: 

1 

"Determine  path  for  process  flow  Scope  Growth  PreB"  ID:  "Decide  121" 

Decide 

BasicProcess 

None 


Column: 


Module  "Determine  path  for  process  flow  Scope  Growth  PreC"  ID:  "Decide  189" 

Type:  Decide 
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From  template: 
Module  Description: 
Operands: 


BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Determine  path  for  process  flow  Scope  Growth  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

80 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

'Determine  quality  values  preB" 

ID:  "Assign  46" 

Type:  Assign 

From  template: 

BasicProcess 

Module  Description: 

None 

Operands: 

Name: 

Determine  quality  values  preB 

Module 

'Determine  quality  values  preC" 

ID:  "Assign  97" 

Type:  Assign 

From  template: 

BasicProcess 

Module  Description: 

None 

Operands: 

Name: 

Determine  quality  values  preC 

Module 

'Determine  trades  delay"  ID:  "Assign  122" 

Type:  Assign 

From  template: 

BasicProcess 

Module  Description: 

None 

Operands: 

Name: 

Determine  trades  delay 

Module 

Type: 

From  template: 
Module  Description: 


"Determine  type  of  requirements  document  needed"  ID:  "Process  5" 

Process 

BasicProcess 

None 
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Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

180 

Minimum: 

14 

Name: 

Determine  type  of  requirements  document  needed 

Priority: 

1 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

118 

"Dev  testing  rework  and  delay"  ID:  "Process  167" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

180 

Minimum: 

30 

Name: 

Dev  testing  rework  and  delay 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

90 

"Develop  AoA  Plan"  ID:  "Process  60" 

Process 

BasicProcess 

None 
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Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

90 

Minimum: 

60 

Name: 

Develop  AoA  Plan 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

75 

"Develop  AoA  Plan  ACAT  I"  ID:  "Process  71" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

90 

Minimum: 

60 

Name: 

Develop  AoA  Plan  ACAT  1 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

75 

"Develop  Courses  of  Action"  ID:  "Process  63" 

Process 

BasicProcess 

None 


698 


Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

180 

Minimum: 

30 

Name: 

Develop  Courses  of  Action 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

160 

"Develop  TandE  strategy  and  Technology  Development  Strategy"  ID:  "Process 
72" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

180 

Minimum: 

30 

Name: 

Develop  TandE  strategy  and  Technology  Development 
Strategy 

Priority: 

2 

Report 

Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

150 

"Developmental  Test  and  Evaluation"  ID:  "Process  163" 
Process 
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From  template: 
Module  Description: 
Operands: 


BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

Developmental  Test  and  Evaluation 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Submodel 

Units: 

Hours 

Value 

1 

Submodel  for  Module  Developmental  Test  and  Evaluation 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Expression 

Expression: 

TRIA(  ,75*testinglength  ,  testinglength  ,  l.l*testinglength  ) 

Maximum: 

250 

Minimum: 

120 

Name: 

ACAT  1  Dev  testing  PreB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

240 

"ACAT  I  Dev  testing  PreB"  ID:  "Process  164" 

Process 

BasicProcess 

None 


Action: 


D 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Expression 

Expression: 

TRIA(  ,75*testinglength  ,  testinglength  ,  l.l*testinglength  ) 

Maximum: 

250 

Minimum: 

120 

Name: 

ACAT  II  Or  III  Dev  testing  PreB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

185 

"ACAT  II  Or  III  Dev  testing  PreB"  ID:  "Process  165" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Assign  value  to  percentage  of  contract  length  ACAT  I  preB"  ID:  "Assign  50" 

Assign 

BasicProcess 

None 


Name: 


Assign  value  to  percentage  of  contract  length  ACAT  I  preB 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Assign  value  to  percentage  of  contract  length  ACAT  II  or  III  preB"  ID:  "Assign 
51" 


Assign 

BasicProcess 

None 


Name: 


Assign  value  to  percentage  of  contract  length  ACAT  II  or  III  preB 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Dev  testing  activities  depend  upon  ACAT  level  preB"  ID:  "Decide  139" 

Decide 

BasicProcess 

None 


Column: 


1 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


If: 

Variable 

Is: 

== 

Name: 

Dev  testing  activities  depend  upon  ACAT  level  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

ACAT  Level 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

"Developmental  system  testing  and  Live  Fire  test  and  Operational  Assessment 
testing"  ID:  "Process  267" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Expression 

TRIA(ACAT  Level==l*0.18*SDD  original  contract  length+ACAT 
Level==2*0.1*SDD  original  contract  length+ACAT 
Level==3*0.1*SDD  original  contract  length, ACAT 
Level==l*0.25*SDD  original  contract  length+ACAT 

Expression: 

Level==2*0.15*SDD  original  contract  length+ACAT 
Level==3*0.15*SDD  original  contract  length, ACAT 
Level==l*0.27*SDD  original  contract  length+ACAT 
Level==2*0.17*SDD  original  contract  length+ACAT 
Level==3*0.17*SDD  original  contract  length) 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

Developmental  system  testing  and  Live  Fire  test  and 

Operational  Assessment  testing 

Priority: 

2 

Report 

Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 
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Value 


1 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Dispose  of  event  happens  prior  to  need"  ID:  "Dispose  31" 

Dispose 

BasicProcess 

None 


Name: 

Dispose  of  event  happens  prior  to  need 

Record  Entity  Statistics 

No 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Dispose  of  event  happens  prior  to  need  PreC"  ID:  "Dispose  46" 

Dispose 

BasicProcess 

None 


Name: 

Dispose  of  event  happens  prior  to  need  PreC 

Record  Entity  Statistics 

No 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Dispose  of  program  review  prior  to  need"  ID:  "Dispose  30" 

Dispose 

BasicProcess 

None 


Name: 

Dispose  of  program  review  prior  to  need 

Record  Entity  Statistics 

No 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Dispose  of  program  review  prior  to  need  PreC"  ID:  "Dispose  45" 

Dispose 

BasicProcess 

None 


Name: 

Dispose  of  program  review  prior  to  need  PreC 

Record  Entity  Statistics 

No 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Draft  RFP  Preparation  preA"  ID:  "Process  73" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

20 

Minimum: 

10 

Name: 

Draft  RFP  Preparation  preA 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

17 

"Draft  RFP  Preparation  preB"  ID:  "Process  140" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

20 

Minimum: 

10 

Name: 

Draft  RFP  Preparation  preB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

17 

"Draft  RFP  Preparation  preC"  ID:  "Process  223" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

704 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

20 

Minimum: 

10 

Name: 

Draft  RFP  Preparation  preC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

17 

"Draft  briefing  and  materials"  ID:  "Process  11" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

40 

Minimum: 

10 

Name: 

Draft  briefing  and  materials 

Priority: 

1 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

31 

"Draft  briefing  and  materials  PreB"  ID:  "Process  82" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

40 

Minimum: 

10 

Name: 

Draft  briefing  and  materials  PreB 

Priority: 

1 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

31 

"Draft  briefing  and  materials  PreC"  ID:  "Process  180" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

40 

Minimum: 

10 

Name: 

Draft  briefing  and  materials  PreC 

Priority: 

1 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

31 

"EOA  rework  and  delay  preB"  ID:  "Process  170" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

180 

Minimum: 

30 

Name: 

EOA  rework  and  delay  preB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

90 

"Early  Archive  End"  ID:  "Dispose  3" 

Dispose 

BasicProcess 

None 


Name: 

Early  Archive  End 

Record  Entity  Statistics 

No 

"Early  Operational  Assessment"  ID:  "Process  166" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

Early  Operational  Assessment 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Submodel 

Units: 

Hours 

Value 

1 
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Submodel  for  Module  Early  Operational  Assessment 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Assign  value  to  percentage  of  contract  length  for  EOA  preB"  ID:  "Assign  52" 

Assign 

BasicProcess 

None 


Name: 


Assign  value  to  percentage  of  contract  length  for  EOA  preB 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Expression 

Expression: 

TRIA(  ,75*testinglength  ,  testinglength  ,  l.l*testinglength  ) 

Maximum: 

250 

Minimum: 

120 

Name: 

EOA  PreB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

240 

"EOA  PreB"  ID:  "Process  168" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  Process  at  COA"  ID:  "Dispose  13" 

Dispose 

BasicProcess 

None 


Name: 

End  Process  at  COA 

Record  Entity  Statistics 

No 

Module  "End  Simulation  5"  ID:  "Assign  60" 

Type:  Assign 
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From  template: 
Module  Description: 
Operands: 


BasicProcess 

None 


Name: 


End  Simulation  5 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  Simulation  8"  ID:  "Assign  77" 

Assign 

BasicProcess 

None 


Name: 


End  Simulation  8 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  Simulation  9"  ID:  "Assign  78" 
Assign 

BasicProcess 

None 


Name: 


End  Simulation  9 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  Simulation  PreB4"  ID:  "Assign  66" 

Assign 

BasicProcess 

None 


Name: 


End  Simulation  PreB  4 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  Simulation  PreC4"  ID:  "Assign  104" 

Assign 

BasicProcess 

None 


Name: 


End  Simulation  PreC  4 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  Time  check"  ID:  "Assign  18" 

Assign 

BasicProcess 

None 


Name: 


End  Time  check 


Module  "End  after  waiting  period"  ID:  "Dispose  33" 

Type:  Dispose 

From  template:  BasicProcess 
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None 


Module  Description: 
Operands: 


Name: 

End  after  waiting  period 

Record  Entity  Statistics 

No 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  at  AoA  check"  ID:  "Dispose  9" 

Dispose 

BasicProcess 

None 


Name: 

End  at  AoA  check 

Record  Entity  Statistics 

No 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  at  MS  C"  ID:  "Dispose  40" 

Dispose 

BasicProcess 

None 


Name: 

End  at  MS  C 

Record  Entity  Statistics 

No 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  of  Event  Happens  Loop  PreB"  ID:  "Dispose  29" 

Dispose 

BasicProcess 

None 


Name: 

End  of  Event  Happens  Loop  PreB 

Record  Entity  Statistics 

No 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  of  Event  Happens  Loop  PreC"  ID:  "Dispose  44" 

Dispose 

BasicProcess 

None 


Name: 

End  of  Event  Happens  Loop  PreC 

Record  Entity  Statistics 

No 

Module  "End  of  Program  Management  and  Oversight  loop"  ID:  "Dispose  27" 

Type:  Dispose 

From  template:  BasicProcess 

Module  Description:  None 
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Operands: 


Name: 

End  of  Program  Management  and  Oversight  loop 

Record  Entity  Statistics 

No 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  of  Program  Management  and  Oversight  loop  PreC"  ID:  "Dispose  42" 

Dispose 

BasicProcess 

None 


Name: 

End  of  Program  Management  and  Oversight  loop 

PreC 

Record  Entity 

Statistics 

No 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  of  Program  Review  Loop"  ID:  "Dispose  24" 

Dispose 

BasicProcess 

None 


Name: 

End  of  Program  Review  Loop 

Record  Entity  Statistics 

No 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  of  Program  Review  Loop  PreC"  ID:  "Dispose  39" 

Dispose 

BasicProcess 

None 


Name: 

End  of  Program  Review  Loop  PreC 

Record  Entity  Statistics 

No 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  of  contract  change  path"  ID:  "Dispose  26" 

Dispose 

BasicProcess 

None 


Name: 

End  of  contract  change  path 

Record  Entity  Statistics 

No 

Module  "End  of  contract  change  path  PreC"  ID:  "Dispose  41" 

Type:  Dispose 

From  template:  BasicProcess 

Module  Description:  None 
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Operands: 


Name: 

End  of  contract  change  path  PreC 

Record  Entity  Statistics 

No 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  prior  to  start  of  Requirements  swimlane  PreB"  ID:  "Dispose  5" 

Dispose 

BasicProcess 

None 


Name: 

End  prior  to  start  of  Requirements  swimlane  PreB 

Record  Entity  Statistics 

No 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  prior  to  start  of  Requirements  swimlane  PreC"  ID:  "Dispose  34" 

Dispose 

BasicProcess 

None 


Name: 

End  prior  to  start  of  Requirements  swimlane  PreC 

Record  Entity  Statistics 

No 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  simulation"  ID:  "Assign  103" 

Assign 

BasicProcess 

None 


Name: 


End  simulation 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  simulation  1"  ID:  "Assign  56" 

Assign 

BasicProcess 

None 


Name: 


End  simulation  1 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  simulation  2"  ID:  "Assign  57" 

Assign 

BasicProcess 

None 


Name: 


End  simulation  2 


Module  "End  simulation  4"  ID:  "Assign  59" 
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Type: 

From  template: 
Module  Description: 
Operands: 


Assign 

BasicProcess 

None 


Name: 


End  simulation  4 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  simulation  6"  ID:  "Assign  61" 
Assign 

BasicProcess 

None 


Name: 


End  simulation  6 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  simulation  7"  ID:  "Assign  62" 

Assign 

BasicProcess 

None 


Name: 


End  simulation  7 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Engineering  Development  model  delivery"  ID:  "Assign  102" 

Assign 

BasicProcess 

None 


Name: 


Engineering  Development  model  delivery 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Entry  after  MS  B"  ID:  "Assign  139" 

Assign 

BasicProcess 

None 


Name: 


Entry  after  MS  B 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Event  Happens  PreB"  ID:  "Decide  145" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Name: 

Event  Happens  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

contract  start 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

"Event  Happens  PreC"  ID:  "Decide  206" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Event  Happens  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Contract  Start  PreC 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

"Fabrication"  ID:  "Process  263" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Expression 

Expression: 

TRIA(.06*SDD  original  contract  length,  ,1*SDD  original 
contract  length,  ,11*SDD  original  contract  length) 

Maximum: 

1.5 

Minimum: 

.5 

714 


Name: 

Fabrication 

Priority: 

2 

Report 

Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Final  PDR"  ID:  "Decide  214" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Final  PDR 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Finalize  RSR  and  calendar  items"  ID:  "Process  15" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

35 

Minimum: 

21 

Name: 

Finalize  RSR  and  calendar  items 

715 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

28 

"Finalize  RSR  and  calendar  items  PreB"  ID:  "Process  88" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

35 

Minimum: 

21 

Name: 

Finalize  RSR  and  calendar  items  PreB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

28 

"Finalize  RSR  and  calendar  items  PreC"  ID:  "Process  182" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

35 

Minimum: 

21 

Name: 

Finalize  RSR  and  calendar  items  PreC 

716 


Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

28 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"First  time  to  contract  completion?"  ID:  "Decide  225" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

First  time  to  contract  completion? 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

End  TD  contract 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

0 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"For  existing  Program?"  ID:  "Decide  1" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

>= 

Name: 

For  existing  Program? 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

75 

Row: 

1 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Type: 

With 

Value: 

1 

"Form  High  Performance  Team"  ID:  "Process  22" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

Wait 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

45 

Minimum: 

30 

Name: 

Form  High  Performance  Team 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

41 

"Form  High  Performance  Team  PreB"  ID:  "Process  90" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

Wait 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

45 

Minimum: 

30 

Name: 

Form  High  Performance  Team  PreB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

718 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Units: 

Days 

Value 

41 

"Form  High  Performance  Team  PreC"  ID:  "Process  184" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

Wait 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

45 

Minimum: 

30 

Name: 

Form  High  Performance  Team  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

41 

"Fully  funded  to  80%  ICE  in  FYDP?  PreC"  ID:  "Decide  179" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Fully  funded  to  80%  ICE  in  FYDP?  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

90 

Row: 

1 

Type: 

With 

Value: 

1 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Funding  problem  Contract  Change  Required  preB"  ID:  "Decide  126" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Funding  problem  Contract  Change  Required  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

40 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Funding  problem  Contract  Change  Required  preC"  ID:  "Decide  192" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Funding  problem  Contract  Change  Required  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

40 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 


"Funds  Available  preA"  ID:  "Decide  55" 

Decide 

BasicProcess 

None 
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Operands: 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Funds  Available  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

75 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Funds  Redirected"  ID:  "Decide  118" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Funds  Redirected 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

20 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Funds  Redirected  PreC"  ID:  "Decide  188" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Funds  Redirected  PreC 

721 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

20 

Row: 

1 

Type: 

With 

Value: 

1 

"Funds  set  aside  for  next  phase  in  FYDP  at  80  percent  of  ICE  amount  PreB"  ID: 
"Decide  106" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Funds  set  aside  for  next  phase  in  FYDP  at  80  percent  of  ICE 
amount  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent 

True 

70 

Row: 

1 

Type: 

With 

Value: 

1 

"High  Performance  Team  work  preA"  ID:  "Process  23" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

7 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Minimum: 

5 

Name: 

High  Performance  Team  work  preA 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

6 

"High  Performance  Team  work  preB"  ID:  "Process  91" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

7 

Minimum: 

5 

Name: 

High  Performance  Team  work  preB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

6 

"High  Performance  Team  work  preC"  ID:  "Process  185" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

7 

723 


Minimum: 

5 

Name: 

High  Performance  Team  work  preC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

6 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


If: 

Entity  Type 

Is: 

>= 

Name: 

In  Scope  of  Existing  document? 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

85 

Row: 

1 

Type: 

With 

Value: 

1 

"In  Scope  of  Existing  document?"  ID:  "Decide  2" 

Decide 

BasicProcess 

None 


Column: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"In  Scope  of  existing  CCD"  ID:  "Assign  137" 

Assign 

BasicProcess 

None 


Name: 


In  Scope  of  existing  CCD 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Independent  Cost  Estimate  PreB"  ID:  "Process  174" 

Process 

BasicProcess 

None 


Action: 


D 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

30 

Name: 

Independent  Cost  Estimate  PreB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

35 

"Independent  Cost  Estimate  PreC"  ID:  "Process  248" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

30 

Name: 

Independent  Cost  Estimate  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

35 

"Independent  document  preA"  ID:  "Process  52" 

Process 

BasicProcess 

None 


Action: 


D 


725 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

Independent  document  preA 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Submodel 

Units: 

Hours 

Value 

1 

Submodel  for  Module  Independent  document  preA 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

30 

Name: 

AFROC  Preparations  indep  preA 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

45 

"AFROC  Preparations  indep  preA"  ID:  "Process  57" 

Process 

BasicProcess 

None 


Action: 


D 


"AFROC  decision  indep  preA"  ID:  "Decide  44" 

Decide 

BasicProcess 


Module 

Type: 

From  template: 


726 


None 


Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

AFROC  decision  indep  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

90 

Row: 

1 

Type: 

With 

Value: 

1 

"Accomplish  Post  AFROC  actions  indep  preA"  ID:  "Process  58" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

15 

Minimum: 

1 

Name: 

Accomplish  Post  AFROC  actions  indep  preA 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

11 

"Air  staff  process  indep  preA"  ID:  "Process  54" 

Process 

BasicProcess 

None 


Action: 


D 


727 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

42 

Minimum: 

21 

Name: 

Air  staff  process  indep  preA 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

29 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Check  for  previous  path  indep  preA"  ID:  "Decide  46" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Check  for  previous  path  indep  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

AFROC  Count 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Critical  comments  indep  preA"  ID:  "Decide  42" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

728 


Name: 

Critical  comments  indep  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

95 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Dead  activity  indep  preA"  ID:  "Decide  45" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Dead  activity  indep  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Death  at  AFROC  indep  preA"  ID:  "Dispose  12" 

Dispose 

BasicProcess 

None 


Name: 

Death  at  AFROC  indep  preA 

Record  Entity  Statistics 

Yes 

Module 

Type: 

From  template: 
Module  Description: 


"Draft  document  indep  preA"  ID:  "Process  53" 

Process 

BasicProcess 

None 


729 


Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

30 

Name: 

Draft  document  indep  preA 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

55 

"End  simulation  preA  1"  ID:  "Assign  129" 

Assign 

BasicProcess 

None 


Name: 


End  simulation  preA  1 


"Hold  for  a  year  later  in  process  indep  preA"  ID:  "Process  56" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

365 

Minimum: 

270 

Name: 

Hold  for  a  year  later  in  process  indep  preA 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

730 


Value 


300 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"MAJCOM  approval  indep  preA"  ID:  "Decide  43" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

MAJCOM  approval  indep  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Post  AFROC  actions  indep  preA"  ID:  "Decide  47" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Post  AFROC  actions  indep  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

25 

Row: 

1 

Type: 

With 

Value: 

1 

Module  "Record  20"  ID:  "Record  20" 

Type:  Record 
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From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


BasicProcess 

None 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  20 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  20 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  20 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

"Set  tracking  indep  PreA"  ID:  "Assign  13" 
Assign 

BasicProcess 

None 


Name: 


Set  tracking  indep  PreA 


"comment  resolution  indep  preA"  ID:  "Process  55" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

45 

Minimum: 

15 

Name: 

comment  resolution  indep  preA 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

30 

732 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

Independent  document  preB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Submodel 

Units: 

Hours 

Value 

1 

"Independent  document  preB"  ID:  "Process  120" 

Process 

BasicProcess 

None 


Action: 


D 


Submodel  for  Module  Independent  document  preB 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"AFROC  Preparations  indep  preB"  ID:  "Process  125" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

30 

Name: 

AFROC  Preparations  indep  preB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Units: 

Days 

Value 

45 

"AFROC  decision  indep  preB"  ID:  "Decide  96" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

AFROC  decision  indep  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

90 

Row: 

1 

Type: 

With 

Value: 

1 

"Accomplish  Post  AFROC  actions  indep  preB"  ID:  "Process  126" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

15 

Minimum: 

1 

Name: 

Accomplish  Post  AFROC  actions  indep  preB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

11 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

42 

Minimum: 

21 

Name: 

Air  staff  process  indep  preB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

29 

"Air  staff  process  indep  preB"  ID:  "Process  122" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Check  for  previous  path  indep  preB"  ID:  "Decide  98" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Check  for  previous  path  indep  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

AFROC  Count  PreB 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

Module 


"Critical  comments  indep  preB"  ID:  "Decide  94" 


735 


Type: 

From  template: 
Module  Description: 
Operands: 


Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Critical  comments  indep  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

95 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Dead  activity  indep  preB"  ID:  "Decide  97" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Dead  activity  indep  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Death  at  AFROC  indep  preB"  ID:  "Dispose  20" 

Dispose 

BasicProcess 

None 


Name: 


Death  at  AFROC  indep  preB 


736 


Record  Entity  Statistics 


Yes 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

30 

Name: 

Draft  document  indep  preB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

55 

"Draft  document  indep  preB"  ID:  "Process  121" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  simulation  preB  1"  ID:  "Assign  63" 

Assign 

BasicProcess 

None 


Name: 


End  simulation  preB  1 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Hold  for  a  year  later  in  process  indep  preB"  ID:  "Process  124" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

365 

Minimum: 

270 

737 


Name: 

Hold  for  a  year  later  in  process  indep  preB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

300 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"MAJCOM  approval  indep  preB"  ID:  "Decide  95" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

MAJCOM  approval  indep  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Post  AFROC  actions  indep  preB"  ID:  "Decide  99" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Post  AFROC  actions  indep  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

25 
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Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Counter  Name: 

Record  23 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  23 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  23 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

"Record  23"  ID:  "Record  23" 

Record 

BasicProcess 

None 


Attribute  Name:  SimTime 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Set  tracking  indep  PreB"  ID:  "Assign  29" 

Assign 

BasicProcess 

None 


Name: 


Set  tracking  indep  PreB 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

45 

Minimum: 

15 

Name: 

comment  resolution  indep  preB 

"comment  resolution  indep  preB"  ID:  "Process  123" 

Process 

BasicProcess 

None 


Action: 


D 
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Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

30 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

Independent  document  preC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Submodel 

Units: 

Hours 

Value 

1 

"Independent  document  preC"  ID:  "Process  214" 

Process 

BasicProcess 

None 


Action: 


D 


Submodel  for  Module  Independent  document  preC 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"AFROC  Preparations  indep  preC"  ID:  "Process  219" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

740 


Maximum: 

60 

Minimum: 

30 

Name: 

AFROC  Preparations  indep  preC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

45 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"AFROC  decision  indep  preC"  ID:  "Decide  175" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

AFROC  decision  indep  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

90 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Accomplish  Post  AFROC  actions  indep  preC"  ID:  "Process  220" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

15 

Minimum: 

1 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Name: 

Accomplish  Post  AFROC  actions  indep  preC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

11 

"Air  staff  process  indep  preC"  ID:  "Process  216" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

42 

Minimum: 

21 

Name: 

Air  staff  process  indep  preC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

29 

"Check  for  previous  path  indep  preC"  ID:  "Decide  177" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Check  for  previous  path  indep  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

742 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Named: 

AFROC  Count  PreC 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

"Critical  comments  indep  preC"  ID:  "Decide  173" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Critical  comments  indep  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

95 

Row: 

1 

Type: 

With 

Value: 

1 

"Dead  activity  indep  preC"  ID:  "Decide  176" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Dead  activity  indep  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 
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Value: 


1 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Death  at  AFROC  indep  preC"  ID:  "Dispose  37" 

Dispose 

BasicProcess 

None 


Name: 

Death  at  AFROC  indep  preC 

Record  Entity  Statistics 

Yes 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

30 

Name: 

Draft  document  indep  preC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

55 

"Draft  document  indep  preC"  ID:  "Process  215" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  simulation  preC  1"  ID:  "Assign  88" 

Assign 

BasicProcess 

None 


Name: 


End  simulation  preC  1 


Module 

Type: 

From  template: 


"Hold  for  a  year  later  in  process  indep  preC"  ID:  "Process  218" 

Process 

BasicProcess 


744 


None 


Module  Description: 
Operands: 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

365 

Minimum: 

270 

Name: 

Hold  for  a  year  later  in  process  indep  preC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

300 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"MAJCOM  approval  indep  preC"  ID:  "Decide  174" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

MAJCOM  approval  indep  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Post  AFROC  actions  indep  preC"  ID:  "Decide  178" 

Decide 

BasicProcess 

None 


Column: 


1 


745 


If: 

Entity  Type 

Is: 

>= 

Name: 

Post  AFROC  actions  indep  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

25 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Record  26"  ID:  "Record  26" 

Record 

BasicProcess 

None 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  26 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  26 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  26 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Set  tracking  indep  PreC"  ID:  "Assign  87" 

Assign 

BasicProcess 

None 


Name: 


Set  tracking  indep  PreC 


Module 

Type: 

From  template: 
Module  Description: 


"Wait  for  successful  Design  Readiness  Review  Indep  PreC"  ID:  "Hold  16" 
Hold 

AdvancedProcess 

None 


746 


Operands: 


Attribute: 

Attribute  1 

Condition: 

DRR  Success==l 

Expression: 

Limit: 

Name: 

Wait  for  successful  Design  Readiness  Review  Indep  PreC 

Queue  Name: 

Wait  for  successful  Design  Readiness  Review  Indep 

PreC. Queue 

Queue  Type: 

Queue 

Queue  Type: 

Queue 

Set  Index: 

1 

Set  Name: 

Wait  for  successful  Design  Readiness  Review  Indep  PreC 

Set. Queue 

Type: 

Scan 

Wait  for 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"comment  resolution  indep  preC"  ID:  "Process  217" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

45 

Minimum: 

15 

Name: 

comment  resolution  indep  preC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

30 

Module 

Type: 

From  template: 


"Initial  Rate  Production  Baseline"  ID:  "Process  270" 

Process 

BasicProcess 


747 


None 


Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

35 

Minimum: 

15 

Name: 

Initial  Rate  Production  Baseline 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

30 

"Integrated  Testing"  ID:  "Process  265" 


Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Expression 

TRIA(ACAT  Level==l*0.15*SDD  original  contract  length+ACAT 
Level==2*0.07*SDD  original  contract  length+ACAT 
Level==3*0.07*SDD  original  contract  length, ACAT 
Level==l*0.25*SDD  original  contract  length+ACAT 

Expression: 

Level==2*0.1*SDD  original  contract  length+ACAT 
Level==3*0.1*SDD  original  contract  length, ACAT 
Level==l*0.26*SDD  original  contract  length+ACAT 
Level==2*0.11*SDD  original  contract  length+ACAT 
Level==3*0.11*SDD  original  contract  length) 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

Integrated  Testing 

Priority: 

2 

Report 

Statistics 

No 

Std  Dev: 

.2 
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Type: 

Standard 

Units: 

Days 

Value 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Joint  Integration  PreA"  ID:  "Process  39" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

Joint  Integration  PreA 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Submodel 

Units: 

Hours 

Value 

1 

Submodel  for  Module  Joint  Integration  PreA 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"AFROC  Preparations  joint  integ  preA"  ID:  "Process  46" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

30 

Name: 

AFROC  Preparations  joint  integ  preA 
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Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

45 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"AFROC  decision  joint  integ  preA"  ID:  "Decide  37" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

AFROC  decision  joint  integ  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

90 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Accomplish  Post  AFROC  actions  joint  integ  preA"  ID:  "Process  49" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

15 

Minimum: 

1 

Name: 

Accomplish  Post  AFROC  actions  joint  integ  preA 

Priority: 

2 

Report  Statistics 

Yes 

750 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

11 

"Air  staff  process  joint  integ  preA"  ID:  "Process  41" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

42 

Minimum: 

21 

Name: 

Air  staff  process  joint  integ  preA 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

29 

"Check  for  previous  path  joint  integ  preA"  ID:  "Decide  39" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Check  for  previous  path  joint  integ  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

AFROC  Count 

Percent  True 

50 

Row: 

1 

751 


Type: 

If 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Critical  comments  joint  integ  preA"  ID:  "Decide  33" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Critical  comments  joint  integ  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

95 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Dead  activity  joint  integ  preA"  ID:  "Decide  38" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Dead  activity  joint  integ  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 


"Death  at  AFROC  joint  integ  preA"  ID:  "Dispose  11" 


752 


Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Dispose 

BasicProcess 

None 


Name: 

Death  at  AFROC  joint  integ  preA 

Record  Entity  Statistics 

Yes 

"Document  review  phase  2  flag  level  joint  integ  preA"  ID:  "Process  43" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

42 

Minimum: 

21 

Name: 

Document  review  phase  2  flag  level  joint  integ  preA 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

34 

"Document  review  phase  joint  integ  preA"  ID:  "Decide  35" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Document  review  phase  joint  integ  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

50 

753 


Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

30 

Name: 

Draft  document  joint  integ  preA 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

55 

"Draft  document  joint  integ  preA"  ID:  "Process  40" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  simulation  Joint  Int  preA  1"  ID:  "Assign  130" 

Assign 

BasicProcess 

None 


Name: 


End  simulation  Joint  Int  preA  1 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Final  AFROC  approval  joint  integ  preA"  ID:  "Decide  41" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Final  AFROC  approval  joint  integ  preA 

754 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

"Final  AFROC  resolution  joint  integ  preA"  ID:  "Process  51" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

42 

Name: 

Final  AFROC  resolution  joint  integ  preA 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

48 

"Flold  for  a  year  later  in  process  2nd  time  joint  integ  preA"  ID:  "Process  48" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

365 

Minimum: 

270 

755 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Name: 

Hold  for  a  year  later  in  process  2nd  time  joint  integ  preA 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

300 

"Hold  for  a  year  later  in  process  joint  integ  preA"  ID:  "Process  47" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

365 

Minimum: 

270 

Name: 

Hold  for  a  year  later  in  process  joint  integ  preA 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

300 

"Interoperability  Certification  joint  integ  preA"  ID:  "Process  45" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

20 

Minimum: 

10 

756 


Name: 

Interoperability  Certification  joint  integ  preA 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

15 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"MAJCOM  approval  joint  integ  preA"  ID:  "Decide  34" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

MAJCOM  approval  joint  integ  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"MAJCOM  approval  later  on  joint  integ  preA"  ID:  "Decide  36" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

MAJCOM  approval  later  on  joint  integ  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

757 


Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


If: 

Entity  Type 

Is: 

>= 

Name: 

Post  AFROC  actions  joint  integ  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

25 

Row: 

1 

Type: 

With 

Value: 

1 

"Post  AFROC  actions  joint  integ  preA"  ID:  "Decide  40" 

Decide 

BasicProcess 

None 


Column: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Counter  Name: 

Record  19 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  19 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  19 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

"Record  19"  ID:  "Record  19" 

Record 

BasicProcess 

None 


Attribute  Name:  SimTime 


Module 


"Resolving  flag  level  comments  joint  integ  preA"  ID:  "Process  44" 


758 


Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

30 

Minimum: 

15 

Name: 

Resolving  flag  level  comments  joint  integ  preA 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

28 

"Set  tracking  joint  integ  PreA"  ID:  "Assign  12" 

Assign 

BasicProcess 

None 


Name: 


Set  tracking  joint  integ  PreA 


"comment  resolution  joint  integ  preA"  ID:  "Process  42" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

45 

Minimum: 

15 

Name: 

comment  resolution  joint  integ  preA 

Priority: 

2 

Report  Statistics 

Yes 

759 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

30 

"document  signing  and  validation  joint  integ  preA"  ID:  "Process  50" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

30 

Minimum: 

14 

Name: 

document  signing  and  validation  joint  integ  preA 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

26 

"Joint  Integration  PreB"  ID:  "Process  107" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

Joint  Integration  PreB 

Priority: 

2 

Report  Statistics 

No 

760 


Std  Dev: 

.2 

Type: 

Submodel 

Units: 

Hours 

Value 

1 

Submodel  for  Module  Joint  Integration  PreB 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

30 

Name: 

AFROC  Preparations  joint  integ  preB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

45 

"AFROC  Preparations  joint  integ  preB"  ID:  "Process  114" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"AFROC  decision  joint  integ  preB"  ID:  "Decide  89" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

AFROC  decision  joint  integ  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

761 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Named: 

Variable  1 

Percent  True 

90 

Row: 

1 

Type: 

With 

Value: 

1 

"Accomplish  Post  AFROC  actions  joint  integ  preB"  ID:  "Process  117" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

15 

Minimum: 

1 

Name: 

Accomplish  Post  AFROC  actions  joint  integ  preB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

11 

"Air  staff  process  joint  integ  preB"  ID:  "Process  109" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

42 

Minimum: 

21 

Name: 

Air  staff  process  joint  integ  preB 

Priority: 

2 

762 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

29 

"Check  for  previous  path  joint  integ  preB"  ID:  "Decide  91" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Check  for  previous  path  joint  integ  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

AFROC  Count  PreB 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

"Critical  comments  joint  integ  preB"  ID:  "Decide  85" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Critical  comments  joint  integ  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

95 

Row: 

1 

Type: 

With 

763 


Value: 


1 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Dead  activity  joint  integ  preB"  ID:  "Decide  90" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Dead  activity  joint  integ  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Death  at  AFROC  joint  integ  preB"  ID:  "Dispose  19" 

Dispose 

BasicProcess 

None 


Name: 

Death  at  AFROC  joint  integ  preB 

Record  Entity  Statistics 

Yes 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Document  review  phase  2  flag  level  joint  integ  preB"  ID:  "Process  111" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

42 

Minimum: 

21 

Name: 

Document  review  phase  2  flag  level  joint  integ  preB 

764 


Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

34 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Document  review  phase  joint  integ  preB"  ID:  "Decide  87" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Document  review  phase  joint  integ  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

50 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Draft  document  joint  integ  preB"  ID:  "Process  108" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

30 

Name: 

Draft  document  joint  integ  preB 

Priority: 

2 

Report  Statistics 

Yes 

765 


Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

55 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  Simulation  PreB  2"  ID:  "Assign  64" 

Assign 

BasicProcess 

None 


Name: 


End  Simulation  PreB  2 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Final  AFROC  approval  joint  integ  preB"  ID:  "Decide  93" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Final  AFROC  approval  joint  integ  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Final  AFROC  resolution  joint  integ  preB"  ID:  "Process  119" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

766 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Minimum: 

42 

Name: 

Final  AFROC  resolution  joint  integ  preB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

48 

"Hold  for  a  year  later  in  process  2nd  time  joint  integ  preB"  ID:  "Process  116" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

365 

Minimum: 

270 

Name: 

Hold  for  a  year  later  in  process  2nd  time  joint  integ  preB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

300 

"Hold  for  a  year  later  in  process  joint  integ  preB"  ID:  "Process  115" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

365 

767 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Minimum: 

270 

Name: 

Hold  for  a  year  later  in  process  joint  integ  preB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

300 

"Interoperability  Certification  joint  integ  preB"  ID:  "Process  113" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

20 

Minimum: 

10 

Name: 

Interoperability  Certification  joint  integ  preB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

15 

"MAJCOM  approval  joint  integ  preB"  ID:  "Decide  86" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

MAJCOM  approval  joint  integ  preB 

Named: 

Attribute  1 

768 


Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"MAJCOM  approval  later  on  joint  integ  preB"  ID:  "Decide  88" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

MAJCOM  approval  later  on  joint  integ  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Post  AFROC  actions  joint  integ  preB"  ID:  "Decide  92" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Post  AFROC  actions  joint  integ  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

25 

Row: 

1 

769 


Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Record  22"  ID: "Record  22" 

Record 

BasicProcess 

None 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  22 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  22 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  22 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

30 

Minimum: 

15 

Name: 

Resolving  flag  level  comments  joint  integ  preB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

28 

"Resolving  flag  level  comments  joint  integ  preB"  ID:  "Process  112" 

Process 

BasicProcess 

None 


Action: 


D 


770 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Set  tracking  joint  integ  PreB"  ID:  "Assign  28" 

Assign 

BasicProcess 

None 


Name: 


Set  tracking  joint  integ  PreB 


"comment  resolution  joint  integ  preB"  ID:  "Process  110" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

45 

Minimum: 

15 

Name: 

comment  resolution  joint  integ  preB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

30 

"document  signing  and  validation  joint  integ  preB"  ID:  "Process  118" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

30 

Minimum: 

14 

Name: 

document  signing  and  validation  joint  integ  preB 

Priority: 

2 

771 


Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

26 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

Joint  Integration  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Submodel 

Units: 

Hours 

Value 

1 

"Joint  Integration  PreC"  ID:  "Process  201" 

Process 

BasicProcess 

None 


Action: 


D 


Submodel  for  Module  Joint  Integration  PreC 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"AFROC  Preparations  joint  integ  preC"  ID:  "Process  208" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

772 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Minimum: 

30 

Name: 

AFROC  Preparations  joint  integ  preC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

45 

"AFROC  decision  joint  integ  preC"  ID:  "Decide  168" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

AFROC  decision  joint  integ  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

90 

Row: 

1 

Type: 

With 

Value: 

1 

"Accomplish  Post  AFROC  actions  joint  integ  preC"  ID:  "Process  211" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

15 

Minimum: 

1 

Name: 

Accomplish  Post  AFROC  actions  joint  integ  preC 

773 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

11 

"Air  staff  process  joint  integ  preC"  ID:  "Process  203" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

42 

Minimum: 

21 

Name: 

Air  staff  process  joint  integ  preC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

29 

"Check  for  previous  path  joint  integ  preC"  ID:  "Decide  170" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Check  for  previous  path  joint  integ  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

AFROC  Count  PreC 

774 


Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Critical  comments  joint  integ  preC"  ID:  "Decide  164" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Critical  comments  joint  integ  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

95 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Dead  activity  joint  integ  preC"  ID:  "Decide  169" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Dead  activity  joint  integ  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

775 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Death  at  AFROC  joint  integ  preC"  ID:  "Dispose  36" 

Dispose 

BasicProcess 

None 


Name: 

Death  at  AFROC  joint  integ  preC 

Record  Entity  Statistics 

Yes 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

42 

Minimum: 

21 

Name: 

Document  review  phase  2  flag  level  joint  integ  preC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

34 

"Document  review  phase  2  flag  level  joint  integ  preC"  ID:  "Process  205" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Document  review  phase  joint  integ  preC"  ID:  "Decide  166" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Document  review  phase  joint  integ  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

776 


Named: 

Variable  1 

Percent  True 

50 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

30 

Name: 

Draft  document  joint  integ  preC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

55 

"Draft  document  joint  integ  preC"  ID:  "Process  202" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  Simulation  PreC  2"  ID:  "Assign  86" 

Assign 

BasicProcess 

None 


Name: 


End  Simulation  PreC  2 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Final  AFROC  approval  joint  integ  preC"  ID:  "Decide  172" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

777 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Is: 

>= 

Name: 

Final  AFROC  approval  joint  integ  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

"Final  AFROC  resolution  joint  integ  preC"  ID:  "Process  213" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

42 

Name: 

Final  AFROC  resolution  joint  integ  preC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

48 

"Hold  for  a  year  later  in  process  2nd  time  joint  integ  preC"  ID:  "Process  210" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

778 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Maximum: 

365 

Minimum: 

270 

Name: 

Hold  for  a  year  later  in  process  2nd  time  joint  integ  preC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

300 

"Hold  for  a  year  later  in  process  joint  integ  preC"  ID:  "Process  209" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

365 

Minimum: 

270 

Name: 

Hold  for  a  year  later  in  process  joint  integ  preC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

300 

"Interoperability  Certification  joint  integ  preC"  ID:  "Process  207" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

779 


Maximum: 

20 

Minimum: 

10 

Name: 

Interoperability  Certification  joint  integ  preC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

15 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"MAJCOM  approval  joint  integ  preC"  ID:  "Decide  165" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

MAJCOM  approval  joint  integ  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"MAJCOM  approval  later  on  joint  integ  preC"  ID:  "Decide  167" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

MAJCOM  approval  later  on  joint  integ  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

780 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

"Post  AFROC  actions  joint  integ  preC"  ID:  "Decide  171" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Post  AFROC  actions  joint  integ  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

25 

Row: 

1 

Type: 

With 

Value: 

1 

"Record  25"  ID:  "Record  25" 

Record 

BasicProcess 

None 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  25 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  25 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  25 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

781 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

30 

Minimum: 

15 

Name: 

Resolving  flag  level  comments  joint  integ  preC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

28 

"Resolving  flag  level  comments  joint  integ  preC"  ID:  "Process  206" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Set  tracking  joint  integ  PreC"  ID:  "Assign  85" 

Assign 

BasicProcess 

None 


Name: 


Set  tracking  joint  integ  PreC 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Wait  for  successful  Design  Readiness  Review  Interest  PreC"  ID:  "Hold  17" 
Hold 

AdvancedProcess 

None 


Attribute: 

Attribute  1 

Condition: 

DRR  Success==l 

Expression: 

Limit: 

Name: 

Wait  for  successful  Design  Readiness  Review  Interest  PreC 

Queue  Name: 

Wait  for  successful  Design  Readiness  Review  Interest 

PreC. Queue 

782 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Queue  Type: 

Queue 

Queue  Type: 

Queue 

Set  Index: 

1 

Set  Name: 

Wait  for  successful  Design  Readiness  Review  Interest  PreC 

Set. Queue 

Type: 

Scan 

Wait  for 

Value: 

1 

"comment  resolution  joint  integ  preC"  ID:  "Process  204" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

45 

Minimum: 

15 

Name: 

comment  resolution  joint  integ  preC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

30 

"document  signing  and  validation  joint  integ  preC"  ID:  "Process  212" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

30 

783 


Minimum: 

14 

Name: 

document  signing  and  validation  joint  integ  preC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

26 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Joint  Interest  preA"  ID:  "Process  24" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

Joint  Interest  preA 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Submodel 

Units: 

Hours 

Value 

1 

Submodel  for  Module  Joint  Interest  preA 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"AFROC  Decision  joint  int  preA"  ID:  "Decide  25" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

784 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Is: 

>= 

Name: 

AFROC  Decision  joint  int  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

90 

Row: 

1 

Type: 

With 

Value: 

1 

"AFROC  Preparations  joint  int  preA"  ID:  "Process  29" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

30 

Name: 

AFROC  Preparations  joint  int  preA 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

45 

"Air  Staff  processes  joint  int  preA"  ID:  "Process  26" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

785 


Maximum: 

42 

Minimum: 

21 

Name: 

Air  Staff  processes  joint  int  preA 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

25 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Check  for  previous  path  joint  int  preA"  ID:  "Decide  28" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Check  for  previous  path  joint  int  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

AFROC  Count 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Comment  Resolution  joint  int  preA"  ID:  "Process  27" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

45 

Minimum: 

15 

786 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Name: 

Comment  Resolution  joint  int  preA 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

30 

"Critical  Comments?  joint  int  preA"  ID:  "Decide  23" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Critical  Comments?  joint  int  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

95 

Row: 

1 

Type: 

With 

Value: 

1 

"Dead  activity  joint  int  preA"  ID:  "Decide  27" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Dead  activity  joint  int  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

787 


Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Death  at  AFROC  joint  int  preA"  ID:  "Dispose  10" 

Dispose 

BasicProcess 

None 


Name: 

Death  at  AFROC  joint  int  preA 

Record  Entity  Statistics 

Yes 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

42 

Minimum: 

21 

Name: 

Document  Reveiw  Phase  2  Flag  Level 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

38 

"Document  Reveiw  Phase  2  Flag  Level"  ID:  "Process  31" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Document  Review  Phase"  ID:  "Decide  29" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

788 


Name: 

Document  Review  Phase 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

50 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  simulation  Joint  Interest  preA  1"  ID:  "Assign  131" 

Assign 

BasicProcess 

None 


Name: 


End  simulation  Joint  Interest  preA  1 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

21 

Minimum: 

7 

Name: 

Functional  Capabilities  Board 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

14 

"Functional  Capabilities  Board"  ID:  "Process  34" 

Process 

BasicProcess 

None 


Action: 


D 


"Hold  for  a  year"  ID:  "Process  28" 

Process 

BasicProcess 


Module 

Type: 

From  template: 


789 


None 


Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

365 

Minimum: 

270 

Name: 

Hold  for  a  year 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

300 

"Hold  for  a  year  later  in  process"  ID:  "Process  33" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

365 

Minimum: 

270 

Name: 

Hold  for  a  year  later  in  process 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

300 

"JCB  issues"  ID:  "Decide  31" 

Decide 

BasicProcess 


790 


None 


Module  Description: 
Operands: 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

JCB  issues 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

15 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"JROC"  ID:  "Decide  32" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

JROC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

98 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"JROC  preparations"  ID:  "Process  37" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

791 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Expression: 

1 

Maximum: 

30 

Minimum: 

14 

Name: 

JROC  preparations 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

25 

"Joint  Capabilities  Board"  ID:  "Process  35" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

21 

Minimum: 

7 

Name: 

Joint  Capabilities  Board 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

14 

"MAJCOM  Approval?  joint  int  preA"  ID:  "Decide  24" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

792 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Name: 

MAJCOM  Approval?  joint  int  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

"MAJCOM  approval"  ID:  "Decide  30" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

MAJCOM  approval 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

"Post  AFROC  actions"  ID:  "Process  30" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

15 

Minimum: 

1 

Name: 

Post  AFROC  actions 

793 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

11 

"Post  AFROC  actions  joint  int  preA"  ID:  "Decide  26" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Post  AFROC  actions  joint  int  preA 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

25 

Row: 

1 

Type: 

With 

Value: 

1 

"Record  18"  ID:  "Record  18" 

Record 

BasicProcess 

None 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  18 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  18 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  18 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

794 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Value: 


1 


"Resolve  JCB  issues"  ID:  "Process  36" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

20 

Minimum: 

10 

Name: 

Resolve  JCB  issues 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

15 

"Resolve  JROC  issues"  ID:  "Process  38" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

42 

Name: 

Resolve  JROC  issues 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

795 


Value 


51 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

30 

Minimum: 

15 

Name: 

Resolving  Flag  level  comments 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

27 

"Resolving  Flag  level  comments"  ID:  "Process  32" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Set  tracking  joint  int  PreA"  ID:  "Assign  10" 

Assign 

BasicProcess 

None 


Name: 


Set  tracking  joint  int  PreA 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"draft  document  preA  joint  interest"  ID:  "Process  25" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

30 

796 


Name: 

draft  document  preA  joint  interest 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

55 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

Joint  Interest  preB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Submodel 

Units: 

Hours 

Value 

1 

"Joint  Interest  preB"  ID:  "Process  92" 

Process 

BasicProcess 

None 


Action: 


D 


Submodel  for  Module  Joint  Interest  preB 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"AFROC  Decision  joint  int  preB"  ID:  "Decide  77" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

797 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Name: 

AFROC  Decision  joint  int  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

90 

Row: 

1 

Type: 

With 

Value: 

1 

"AFROC  Preparations  joint  int  preB"  ID:  "Process  97" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

30 

Name: 

AFROC  Preparations  joint  int  preB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

45 

"Air  Staff  processes  joint  int  preB"  ID:  "Process  94" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

42 

798 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Minimum: 

21 

Name: 

Air  Staff  processes  joint  int  preB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

25 

"Check  for  previous  path  joint  int  preB"  ID:  "Decide  80" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Check  for  previous  path  joint  int  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

AFROC  Count 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

"Comment  Resolution  joint  int  preB"  ID:  "Process  95" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

45 

Minimum: 

15 

Name: 

Comment  Resolution  joint  int  preB 

799 


Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

30 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Critical  Comments?  joint  int  preB"  ID:  "Decide  75" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Critical  Comments?  joint  int  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

95 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Dead  activity  joint  int  preB"  ID:  "Decide  79" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Dead  activity  joint  int  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

800 


Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Death  at  AFROC  joint  int  preB"  ID:  "Dispose  18" 

Dispose 

BasicProcess 

None 


Name: 

Death  at  AFROC  joint  int  preB 

Record  Entity  Statistics 

Yes 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

42 

Minimum: 

21 

Name: 

Document  Reveiw  Phase  2  Flag  Level  PreB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

38 

"Document  Reveiw  Phase  2  Flag  Level  PreB"  ID:  "Process  99" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Document  Review  Phase  PreB"  ID:  "Decide  81" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Document  Review  Phase  PreB 

801 


Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

50 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  Simulation  PreB  3"  ID:  "Assign  65" 

Assign 

BasicProcess 

None 


Name: 


End  Simulation  PreB  3 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

21 

Minimum: 

7 

Name: 

Functional  Capabilities  Board  PreB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

14 

"Functional  Capabilities  Board  PreB"  ID:  "Process  102" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 


"Hold  for  a  year  PreB"  ID:  "Process  96" 

Process 

BasicProcess 

None 


802 


Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

365 

Minimum: 

270 

Name: 

Hold  for  a  year  PreB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

300 

"Hold  for  a  year  later  in  process  PreB"  ID:  "Process  101" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

365 

Minimum: 

270 

Name: 

Hold  for  a  year  later  in  process  PreB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

300 

"JCB  issues  PreB"  ID:  "Decide  83" 

Decide 

BasicProcess 

None 


803 


Operands: 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

JCB  issues  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

15 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"JROC  PreB"  ID:  "Decide  84" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

JROC  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

98 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"JROC  preparations  PreB"  ID:  "Process  105" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

804 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Maximum: 

30 

Minimum: 

14 

Name: 

JROC  preparations  PreB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

25 

"Joint  Capabilities  Board  PreB"  ID:  "Process  103" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

21 

Minimum: 

7 

Name: 

Joint  Capabilities  Board  PreB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

14 

"MAJCOM  Approval?  joint  int  preB"  ID:  "Decide  76" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

MAJCOM  Approval?  joint  int  preB 

805 


Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"MAJCOM  approval  PreB"  ID:  "Decide  82" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

MAJCOM  approval  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Post  AFROC  actions  PreB"  ID:  "Process  98" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

15 

Minimum: 

1 

Name: 

Post  AFROC  actions  PreB 

Priority: 

2 

806 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

11 

"Post  AFROC  actions  joint  int  preB"  ID:  "Decide  78" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Post  AFROC  actions  joint  int  preB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

25 

Row: 

1 

Type: 

With 

Value: 

1 

"Record  21"  ID: "Record  21" 

Record 

BasicProcess 

None 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  21 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  21 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  21 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

807 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Resolve  JCB  issues  PreB"  ID:  "Process  104" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

20 

Minimum: 

10 

Name: 

Resolve  JCB  issues  PreB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

15 

"Resolve  JROC  issues  PreB"  ID:  "Process  106" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

42 

Name: 

Resolve  JROC  issues  PreB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

51 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

30 

Minimum: 

15 

Name: 

Resolving  Flag  level  comments  PreB 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

27 

"Resolving  Flag  level  comments  PreB"  ID:  "Process  100" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Set  tracking  joint  int  PreB"  ID:  "Assign  26" 

Assign 

BasicProcess 

None 


Name: 


Set  tracking  joint  int  PreB 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"draft  document  preB  joint  interest"  ID:  "Process  93" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

30 

Name: 

draft  document  preB  joint  interest 

809 


Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

55 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

Joint  Interest  preC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Submodel 

Units: 

Hours 

Value 

1 

"Joint  Interest  preC"  ID:  "Process  186" 

Process 

BasicProcess 

None 


Action: 


D 


Submodel  for  Module  Joint  Interest  preC 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"AFROC  Decision  joint  int  preC"  ID:  "Decide  156" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

AFROC  Decision  joint  int  preC 

810 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

90 

Row: 

1 

Type: 

With 

Value: 

1 

"AFROC  Preparations  joint  int  preC"  ID:  "Process  191" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

30 

Name: 

AFROC  Preparations  joint  int  preC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

45 

"Air  Staff  processes  joint  int  preC"  ID:  "Process  188" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

42 

Minimum: 

21 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Name: 

Air  Staff  processes  joint  int  preC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

25 

"Check  for  previous  path  joint  int  preC"  ID:  "Decide  159" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Check  for  previous  path  joint  int  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

AFROC  Count  PreC 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

"Comment  Resolution  joint  int  preC"  ID:  "Process  189" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

45 

Minimum: 

15 

Name: 

Comment  Resolution  joint  int  preC 

Priority: 

2 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

30 

"Critical  Comments?  joint  int  preC"  ID:  "Decide  154" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Critical  Comments?  joint  int  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

95 

Row: 

1 

Type: 

With 

Value: 

1 

"Dead  activity  joint  int  preC"  ID:  "Decide  158" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Dead  activity  joint  int  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

813 


Value: 


1 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Death  at  AFROC  joint  int  preC"  ID:  "Dispose  35" 

Dispose 

BasicProcess 

None 


Name: 

Death  at  AFROC  joint  int  preC 

Record  Entity  Statistics 

Yes 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

42 

Minimum: 

21 

Name: 

Document  Reveiw  Phase  2  Flag  Level  PreC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

38 

"Document  Reveiw  Phase  2  Flag  Level  PreC"  ID:  "Process  193" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Document  Review  Phase  PreC"  ID:  "Decide  160" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Document  Review  Phase  PreC 

Named: 

Attribute  1 

814 


Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

50 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"End  Simulation  PreC  3"  ID:  "Assign  83" 

Assign 

BasicProcess 

None 


Name: 


End  Simulation  PreC  3 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

21 

Minimum: 

7 

Name: 

Functional  Capabilities  Board  PreC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

14 

"Functional  Capabilities  Board  PreC"  ID:  "Process  196" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Hold  for  a  year  PreC"  ID:  "Process  190" 

Process 

BasicProcess 

None 


Action: 


D 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

365 

Minimum: 

270 

Name: 

Hold  for  a  year  PreC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

300 

"Hold  for  a  year  later  in  process  PreC"  ID:  "Process  195" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

365 

Minimum: 

270 

Name: 

Hold  for  a  year  later  in  process  PreC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

300 

"JCB  issues  PreC"  ID:  "Decide  162" 

Decide 

BasicProcess 

None 


Column: 


1 


816 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


If: 

Entity  Type 

Is: 

>= 

Name: 

JCB  issues  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

15 

Row: 

1 

Type: 

With 

Value: 

1 

"JROC  PreC"  ID:  "Decide  163" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

JROC  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

98 

Row: 

1 

Type: 

With 

Value: 

1 

"JROC  preparations  PreC"  ID:  "Process  199" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

30 

817 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Minimum: 

14 

Name: 

JROC  preparations  PreC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

25 

"Joint  Capabilities  Board  PreC"  ID:  "Process  197" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

21 

Minimum: 

7 

Name: 

Joint  Capabilities  Board  PreC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

14 

"MAJCOM  Approval?  joint  int  preC"  ID:  "Decide  155" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

MAJCOM  Approval?  joint  int  preC 

Named: 

Attribute  1 

818 


Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"MAJCOM  approval  PreC"  ID:  "Decide  161" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

MAJCOM  approval  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Post  AFROC  actions  PreC"  ID:  "Process  192" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

15 

Minimum: 

1 

Name: 

Post  AFROC  actions  PreC 

Priority: 

2 

Report  Statistics 

Yes 

819 


Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

11 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


If: 

Entity  Type 

Is: 

>= 

Name: 

Post  AFROC  actions  joint  int  preC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

25 

Row: 

1 

Type: 

With 

Value: 

1 

"Post  AFROC  actions  joint  int  preC"  ID:  "Decide  157" 

Decide 

BasicProcess 

None 


Column: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Counter  Name: 

Record  24 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  24 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  24 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

"Record  24"  ID:  "Record  24" 

Record 

BasicProcess 

None 


Attribute  Name:  SimTime 


820 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Resolve  JCB  issues  PreC"  ID:  "Process  198" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

20 

Minimum: 

10 

Name: 

Resolve  JCB  issues  PreC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

15 

"Resolve  JROC  issues  PreC"  ID:  "Process  200" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

42 

Name: 

Resolve  JROC  issues  PreC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

51 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Resolving  Flag  level  comments  PreC"  ID:  "Process  194" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

30 

Minimum: 

15 

Name: 

Resolving  Flag  level  comments  PreC 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

27 

"Set  tracking  joint  int  PreC"  ID:  "Assign  82" 

Assign 

BasicProcess 

None 


Name: 


Set  tracking  joint  int  PreC 


"Wait  for  successful  Design  Readiness  Review  Joint  PreC"  ID:  "Hold  18" 
Hold 

AdvancedProcess 

None 


Attribute: 

Attribute  1 

Condition: 

DRR  Success==l 

Expression: 

Limit: 

Name: 

Wait  for  successful  Design  Readiness  Review  Joint  PreC 

Queue  Name: 

Wait  for  successful  Design  Readiness  Review  Joint 

PreC. Queue 

Queue  Type: 

Queue 

822 


Queue  Type: 

Queue 

Set  Index: 

1 

Set  Name: 

Wait  for  successful  Design  Readiness  Review  Joint  PreC 

Set. Queue 

Type: 

Scan 

Wait  for 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"draft  document  preC  joint  interest"  ID:  "Process  187" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

30 

Name: 

draft  document  preC  joint  interest 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

55 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"KPP  Development"  ID:  "Process  79" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Expression 

Expression: 

TRIA(0.65*TD  original  contract  length,  ,72*TD  original 
contract  length,  0.75*TD  original  contract  length) 

Maximum: 

1.5 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Minimum: 

.5 

Name: 

KPP  Development 

Priority: 

2 

Report 

Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

1 

"KPPs  arrive  from  Requirements"  ID:  "Hold  3" 
Hold 

AdvancedProcess 

None 


Attribute: 

Attribute  1 

Condition: 

KPPs  Ready  PreB==l 

Expression: 

Limit: 

|  t 

Name: 

KPPs  arrive  from  Requirements 

Queue  Name: 

KPPs  arrive  from  Requirements. Queue 

Queue  Type: 

Queue 

Queue  Type: 

Queue 

Set  Index: 

1 

Set  Name: 

KPPs  arrive  from  Requirements  Set. Queue 

Type: 

Scan 

Wait  for  Value: 

4 

"KPPs  arrive  from  Requirements  PreC"  ID:  "Hold  12" 
Hold 

AdvancedProcess 

None 


Attribute: 

Attribute  1 

Condition: 

KPPs  Ready  PreC==l 

Expression: 

— 

Limit: 

Name: 

KPPs  arrive  from  Requirements  PreC 
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Queue  Name: 

KPPs  arrive  from  Requirements  PreC. Queue 

Queue  Type: 

Queue 

Queue  Type: 

Queue 

Set  Index: 

1 

Set  Name: 

KPPs  arrive  from  Requirements  PreC  Set. Queue 

Type: 

Scan 

Wait  for  Value: 

4 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Kill  at  MS  A  decision"  ID:  "Dispose  15" 

Dispose 

BasicProcess 

None 


Name: 

Kill  at  MS  A  decision 

Record  Entity  Statistics 

No 

Module  "Kill  at  MS  B  decision"  ID:  "Dispose  23" 


Type: 

Dispose 

From  template: 

BasicProcess 

Module  Description: 

None 

Operands: 

Name: 

Kill  at  MS  B  decision 

Record  Entity  Statistics 

No 

Module 

'Kill  at  MS  C  decision"  ID:  "Dispose  38" 

Type: 

Dispose 

From  template: 

BasicProcess 

Module  Description: 

None 

Operands: 

Name: 

Kill  at  MS  C  decision 

Record  Entity  Statistics 

No 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Kill  by  MDA  at  Concept  Decision"  ID:  "Dispose  14" 

Dispose 

BasicProcess 

None 


Name: 

Kill  by  MDA  at  Concept  Decision 

Record  Entity  Statistics 

No 

825 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Kill  program  at  selected  COA"  ID:  "Assign  16" 

Assign 

BasicProcess 

None 


Name: 


Kill  program  at  selected  COA 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Logic  check  for  ACAT  level  PreB"  ID:  "Decide  134" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Logic  check  for  ACAT  level  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

ACAT  Level 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"MAJCOM  A  Letters  Coordinate  and  Concur"  ID:  "Decide  9" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

MAJCOM  A  Letters  Coordinate  and  Concur 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

80 

Row: 

1 

Type: 

With 

826 


Value: 


1 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"MAJCOM  A  Letters  Coordinate  and  Concur  PreB"  ID:  "Decide  66" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

MAJCOM  A  Letters  Coordinate  and  Concur  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

90 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"MAJCOM  A  Letters  Coordinate  and  Concur  PreC"  ID:  "Decide  148" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

MAJCOM  A  Letters  Coordinate  and  Concur  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

90 

Row: 

1 

Type: 

With 

Value: 

1 

Module  "MDA  Milestone  approval"  ID:  "Decide  61" 

Type:  Decide 


827 


From  template: 
Module  Description: 
Operands: 


BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

MDA  Milestone  approval 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"MDA  Milestone  approval  PreB"  ID:  "Decide  112" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

MDA  Milestone  approval  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"MDA  Milestone  approval  PreC"  ID:  "Decide  182" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

828 


Is: 

>= 

Name: 

MDA  Milestone  approval  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

90 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"MDAP  Threshold  crossed?"  ID:  "Decide  6" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

MDAP  Threshold  crossed? 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

10 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"MS  A  decision"  ID:  "Assign  22" 

Assign 

BasicProcess 

None 


Name: 


MS  A  decision 


Module 

Type: 

From  template: 
Module  Description: 


"MS  B  decision"  ID:  "Assign  38" 

Assign 

BasicProcess 

None 


829 


Operands: 


Name: 


MS  B  decision 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"MS  C  decision"  ID:  "Assign  90" 

Assign 

BasicProcess 

None 


Name: 


MS  C  decision 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


If: 

Entity  Type 

Is: 

>= 

Name: 

Make  Trades? 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

50 

Row: 

1 

Type: 

With 

Value: 

1 

"Make  Trades?"  ID:  "Decide  221" 

Decide 

BasicProcess 

None 


Column: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Non  AoA  Route"  ID:  "Separate  28" 

Separate 

BasicProcess 

None 


#  of  Duplicates: 

1 

Member  Attributes: 

Retain  Original  Entity  Values 

Name: 

Non  AoA  Route 

Percent  Cost  to  Duplicates 

0 

Type: 

Duplicate 

Module  "Notify  PreC  Baseline"  ID:  "Assign  128" 

Type:  Assign 


830 


BasicProcess 

None 


From  template: 
Module  Description: 
Operands: 


Name: 


Notify  PreC  Baseline 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Notify  Requirements  about  DRR  success"  ID:  "Assign  124" 

Assign 

BasicProcess 

None 


Name: 


Notify  Requirements  about  DRR  success 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"OR  junction"  ID:  "Decide  4" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

OR  junction 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

75 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


If: 

Entity  Type 

Is: 

>= 

Name: 

Obtain  funds  in  a  timely  manner  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

"Obtain  funds  in  a  timely  manner  PreB"  ID:  "Decide  123" 

Decide 

BasicProcess 

None 


Column: 


831 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Named: 

Variable  1 

Percent  True 

65 

Row: 

1 

Type: 

With 

Value: 

1 

"Obtain  funds  in  a  timely  manner  PreC"  ID:  "Decide  191" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Obtain  funds  in  a  timely  manner  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

65 

Row: 

1 

Type: 

With 

Value: 

1 

"PDR  2"  ID:  "Decide  212" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

PDR  2 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

50 

Row: 

1 

Type: 

With 

832 


Value: 


1 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"PDR  3"  ID:  "Decide  213" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

PDR  3 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

90 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Expression 

Expression: 

PDR  rework 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

PDR  Rework  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

1 

"PDR  Rework  PreC"  ID:  "Process  254" 

Process 

BasicProcess 

None 


Action: 


D 


833 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Expression 

Expression: 

PDR  Rework 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

PDR  delay  2  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

1 

"PDR  delay  2  PreC"  ID:  "Process  255" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"PDR  delay  3  PreC"  ID:  "Process  256" 


Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Expression 

Expression: 

PDR  Rework 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

PDR  delay  3  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

1 

834 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"PDR  success??"  ID:  "Decide  211" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

PDR  success?? 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

25 

Row: 

1 

Type: 

With 

Value: 

1 

"PEM  or  other  staff  find  money  PreB"  ID:  "Process  177" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Expression 

Expression: 

(ACAT  level==l)*TRIA(14,83,180)+(ACAT 

level==2)*TRIA(14,160,180)+(ACAT 

level==3)*TRIA(14,160,180) 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

PEM  or  other  staff  find  money  PreB 

Priority: 

2 

Report 

Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

1 

835 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"PEM  or  other  staff  find  money  PreC"  ID:  "Process  251" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Expression 

Expression: 

(ACAT  level==l)*TRIA(14,83,180)+(ACAT 

level==2)*TRIA(14,160,180)+(ACAT 

level==3)*TRIA(14,160,180) 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

PEM  or  other  staff  find  money  PreC 

Priority: 

2 

Report 

Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

1 

"Path  depends  upon  ACAT  level  PreB"  ID:  "Decide  116" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Path  depends  upon  ACAT  level  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

50 

Row: 

1 

Type: 

Nlf 

Value: 

1 

836 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 


"Path  depends  upon  ACAT  level  PreC"  ID:  "Decide  186" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Path  depends  upon  ACAT  level  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

50 

Row: 

1 

Type: 

Nlf 

Value: 

1 

"Pre  DRR  Acquisition  Panels"  ID:  "Process  261" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

15 

Minimum: 

3 

Name: 

Pre  DRR  Acquisition  Panels 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

12 

"PreRSR  MAJCOM  A8"  ID:  "Decide  11" 
Decide 


837 


From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

PreRSR  MAJCOM  A8 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

95 

Row: 

1 

Type: 

With 

Value: 

1 

"PreRSR  MAJCOM  A8  PreB"  ID:  "Decide  69" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

PreRSR  MAJCOM  A8  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

"PreRSR  MAJCOM  A8  PreC"  ID:  "Decide  149" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

838 


Is: 

>= 

Name: 

PreRSR  MAJCOM  A8  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

99 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Preferred  System  Concept  Named"  ID:  "Assign  20" 

Assign 

BasicProcess 

None 


Name: 


Preferred  System  Concept  Named 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


If: 

Expression 

Is: 

== 

Name: 

Preliminary  Design  Review 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

ACAT  Level 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

TNOW.GE.(  (  SDD  contract  length  *  .25  )  +  SDD  Contract  Start ) 

"Preliminary  Design  Review"  ID:  "Decide  196" 

Decide 

BasicProcess 

None 


Column: 


Module  "Preparation  for  Acqiusition  Panels  before  DRR"  ID:  "Process  260" 

Type:  Process 

From  template:  BasicProcess 

Module  Description:  None 


839 


Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

60 

Minimum: 

25 

Name: 

Preparation  for  Acqiusition  Panels  before  DRR 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

50 

"Prepare  Concept  of  Operation"  ID:  "Process  178" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Expression 

Expression: 

TRIA(0.6*SDD  original  contract  length,  0.7*SDD  original 
contract  length,  0.8*SDD  original  contract  length) 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

Prepare  Concept  of  Operation 

Priority: 

2 

Report 

Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

1 

"Prepare  Courses  of  Action  PreB"  ID:  "Process  149" 
Process 


840 


From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 


BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

10 

Minimum: 

5 

Name: 

Prepare  Courses  of  Action  PreB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

8 

"Prepare  Courses  of  Action  PreC"  ID:  "Process  232" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

10 

Minimum: 

5 

Name: 

Prepare  Courses  of  Action  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

8 

"Prepare  for  Acquisition"  ID:  "Process  3" 
Process 


841 


From  template: 
Module  Description: 
Operands: 


BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

1460 

Minimum: 

5 

Name: 

Prepare  for  Acquisition 

Priority: 

1 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

7 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Processes  come  together"  ID:  "Batch  3" 
Batch 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Batch  Size: 

2 

Name: 

Processes  come  together 

Representative  Entity  Type: 

Rule: 

Any  Entity 

Save  Criterion: 

Last 

Type: 

Permanent 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Processes  come  together  PreB"  ID:  "Batch  7" 
Batch 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Batch  Size: 

2 

Name: 

Processes  come  together  PreB 

Representative  Entity  Type: 

842 


Rule: 

Any  Entity 

Save  Criterion: 

Last 

Type: 

Permanent 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Batch  Size: 

2 

Name: 

Processes  come  together  PreC 

Representative  Entity  Type: 

Rule: 

Any  Entity 

Save  Criterion: 

Last 

Type: 

Permanent 

"Processes  come  together  PreC"  ID:  "Batch  15" 
Batch 

BasicProcess 

None 


Attribute  Name: 


Attribute  1 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Program  Kill  at  CDR"  ID:  "Dispose  48" 

Dispose 

BasicProcess 

None 


Name: 

Program  Kill  at  CDR 

Record  Entity  Statistics 

No 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Program  Kill  at  PDR"  ID:  "Dispose  47" 

Dispose 

BasicProcess 

None 


Name: 

Program  Kill  at  PDR 

Record  Entity  Statistics 

No 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Program  Office  Cost  Estimate  PreB"  ID:  "Process  172" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

843 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

90 

Minimum: 

60 

Name: 

Program  Office  Cost  Estimate  PreB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

65 

"Program  Office  Cost  Estimate  PreC"  ID:  "Process  246" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

90 

Minimum: 

60 

Name: 

Program  Office  Cost  Estimate  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

65 

"Program  Review  OK"  ID:  "Decide  117" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

844 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Is: 

>= 

Name: 

Program  Review  OK 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

95 

Row: 

1 

Type: 

With 

Value: 

1 

"Program  Review  OK  PreC"  ID:  "Decide  187" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

>= 

Name: 

Program  Review  OK  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

95 

Row: 

1 

Type: 

With 

Value: 

1 

"Program  review  condition"  ID:  "Create  4" 

Create 

BasicProcess 

None 


Entities  per 
Arrival: 

1 

Entity  Type: 

P  rogram  reviewp  re  B 

Expression: 

(ACAT  level==l)  *TRIA(  90 , 105 , 120  )  +  (ACAT  level  ==2)  * 
TRIA(160,180,200)+  (ACAT  level  ==3)  *  TRIA(160,180,200) 

First  Creation: 

0.00 

845 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Max  Arrivals: 

Infinite 

Name: 

Program  review  condition 

Schedule 

Name: 

Schedule  1 

Type: 

Expression 

Units: 

Days 

Value: 

1 

"Program  review  condition  PreC"  ID:  "Create  6" 

Create 

BasicProcess 

None 


Entities  per 
Arrival: 

1 

Entity  Type: 

ProgramreviewpreC 

Expression: 

(ACAT  level==l)  *TRIA(  90 , 105 , 120  )  +  (ACAT  level  ==2)  * 
TRIA(160,180,200)+  (ACAT  level  ==3)  *  TRIA(160,180,200) 

First  Creation: 

0 

Max  Arrivals: 

Infinite 

Name: 

Program  review  condition  PreC 

Schedule 

Name: 

Schedule  1 

Type: 

Expression 

Units: 

Days 

Value: 

1 

"Protest  award  PreB"  ID:  "Decide  114" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Protest  award  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

846 


Percent  True 

20 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Protest  award  PreC"  ID:  "Decide  184" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Protest  award  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

20 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Protest  upheld"  ID:  "Decide  115" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Protest  upheld 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

40 

Row: 

1 

Type: 

With 

Value: 

1 

847 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


If: 

Entity  Type 

Is: 

>= 

Name: 

Protest  upheld  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

40 

Row: 

1 

Type: 

With 

Value: 

1 

"Protest  upheld  PreC"  ID:  "Decide  185" 

Decide 

BasicProcess 

None 


Column: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


If: 

Expression 

Is: 

<= 

Name: 

Query  contract  elapsed  time  6  months  to  completion  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Technology  Development  Contract  length 

Percent 

True 

50 

Row: 

1 

Type: 

If 

Value: 

TNOW.GE.  (  TD  Contract  End  Date-180)  |  |  TD  Contract  End 

Date  Near 

"Query  contract  elapsed  time  6  months  to  completion  PreB"  ID:  "Decide  136" 

Decide 

BasicProcess 

None 


Column: 


Module  "Query  contract  elapsed  time  6  months  to  completion  PreC"  ID:  "Decide  198" 

Type:  Decide 
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From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 


BasicProcess 

None 


Column: 

1 

If: 

Expression 

Is: 

<= 

Name: 

Query  contract  elapsed  time  6  months  to  completion  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Technology  Development  Contract  length 

Percent 

True 

50 

Row: 

1 

Type: 

If 

Value: 

TNOW.GE.(SDD  Contract  End  Date-180)  |  |  SDD  Contract 
condition  end  is  close 

"RFP  Coordination  Process"  ID:  "Process  74" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

50 

Minimum: 

25 

Name: 

RFP  Coordination  Process 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

45 

"RFP  Coordination  Process  PreB"  ID:  "Process  141" 

Process 

BasicProcess 
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None 


Module  Description: 
Operands: 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

50 

Minimum: 

25 

Name: 

RFP  Coordination  Process  PreB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

45 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"RFP  Coordination  Process  PreC"  ID:  "Process  224" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

50 

Minimum: 

25 

Name: 

RFP  Coordination  Process  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

45 

Module 

Type: 

From  template: 


"RFP  Release  and  Source  Selection  PreB"  ID:  "Process  146" 

Process 

BasicProcess 
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None 


Module  Description: 
Operands: 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

180 

Minimum: 

90 

Name: 

RFP  Release  and  Source  Selection  PreB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

160 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"RFP  Release  and  Source  Selection  PreC"  ID:  "Process  229" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

180 

Minimum: 

90 

Name: 

RFP  Release  and  Source  Selection  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

160 

Module 

Type: 

From  template: 


"RSR  HQ  USAF  A5R"  ID:  "Decide  12" 

Decide 

BasicProcess 
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None 


Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

RSR  HQ  USAF  A5R 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

98 

Row: 

1 

Type: 

With 

Value: 

1 

"RSR  HQ  USAF  A5R  PreB"  ID:  "Decide  70" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

RSR  HQ  USAF  A5R  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

98 

Row: 

1 

Type: 

With 

Value: 

1 

"RSR  HQ  USAF  A5R  PreC"  ID:  "Decide  150" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

852 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Name: 

RSR  HQUSAF  A5R  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

98 

Row: 

1 

Type: 

With 

Value: 

1 

"Random  Entry  Point"  ID:  "Process  1" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

Other 

Delay  Type: 

Uniform 

Expression: 

TRIA(  Min,  Mode,  Max) 

Maximum: 

365 

Minimum: 

1 

Name: 

Random  Entry  Point 

Priority: 

1 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

1 

"Receipt  of  approved  CCD"  ID:  "Batch  14" 
Batch 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Batch  Size: 

2 

Name: 

Receipt  of  approved  CCD 

Representative  Entity  Type: 

Rule: 

Any  Entity 
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Save  Criterion: 

Last 

Type: 

Permanent 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Receipt  of  approved  CPD"  ID:  "Batch  19" 
Batch 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Batch  Size: 

2 

Name: 

Receipt  of  approved  CPD 

Representative  Entity  Type: 

Rule: 

Any  Entity 

Save  Criterion: 

Last 

Type: 

Permanent 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Record  1"  ID:  "Record  1" 

Record 

BasicProcess 

None 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  1 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  1 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  1 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Record  10"  ID:  "Record  10" 

Record 

BasicProcess 

None 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  10 
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Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  10 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  10 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Counter  Name: 

Record  11 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  11 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  11 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

"Record  11"  ID:  "Record  11" 

Record 

BasicProcess 

None 


Attribute  Name:  SimTime 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Counter  Name: 

Record  12 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  12 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  12 

Tally  Set  Name: 

Tally  Set  1 

"Record  12"  ID:  "Record  12" 

Record 

BasicProcess 

None 


Attribute  Name:  SimTime 


855 


Type: 

Interval 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Record  13"  ID:  "Record  13" 

Record 

BasicProcess 

None 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  13 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  13 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  13 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Record  14"  ID:  "Record  14" 

Record 

BasicProcess 

None 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  14 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  14 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  14 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

Module 

Type: 

From  template: 


"Record  15"  ID:  "Record  15" 

Record 

BasicProcess 
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None 


Module  Description: 
Operands: 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  15 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  15 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  15 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Counter  Name: 

Record  16 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  16 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  16 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

"Record  16"  ID:  "Record  16" 

Record 

BasicProcess 

None 


Attribute  Name:  SimTime 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Record  17"  ID:  "Record  17" 

Record 

BasicProcess 

None 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  17 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  17 

Record  into  Set 

No 
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Set  Index: 

1 

Tally  Name: 

Record  17 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Counter  Name: 

Record  2 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  2 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  2 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

"Record  2"  ID:  "Record  2" 

Record 

BasicProcess 

None 


Attribute  Name:  SimTime 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Counter  Name: 

Record  3 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  3 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  3 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

"Record  3"  ID:  "Record  3" 

Record 

BasicProcess 

None 


Attribute  Name:  SimTime 


858 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Record  33"  ID:  "Record  33" 

Record 

BasicProcess 

None 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  33 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  33 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  33 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Record  34"  ID:  "Record  34" 

Record 

BasicProcess 

None 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  34 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  34 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  34 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Record  35"  ID:  "Record  35" 

Record 

BasicProcess 

None 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  35 
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Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  35 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  35 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Counter  Name: 

Record  36 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  36 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  36 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

"Record  36"  ID:  "Record  36" 

Record 

BasicProcess 

None 


Attribute  Name:  SimTime 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Counter  Name: 

Record  37 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  37 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  37 

Tally  Set  Name: 

Tally  Set  1 

"Record  37" ID: "Record  37" 

Record 

BasicProcess 

None 


Attribute  Name:  SimTime 


860 


Type: 

Interval 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Record  38"  ID: "Record  38" 

Record 

BasicProcess 

None 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  38 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  38 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  38 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Record  39"  ID: "Record  39" 

Record 

BasicProcess 

None 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  39 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  39 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  39 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

Module 

Type: 

From  template: 


"Record  4"  ID:  "Record  4" 

Record 

BasicProcess 
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None 


Module  Description: 
Operands: 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  4 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  4 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  4 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Counter  Name: 

Record  40 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  40 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  40 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

"Record  40"  ID:  "Record  40" 

Record 

BasicProcess 

None 


Attribute  Name:  SimTime 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Record  41"  ID:  "Record  41" 

Record 

BasicProcess 

None 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  41 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  41 

Record  into  Set 

No 
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Set  Index: 

1 

Tally  Name: 

Record  41 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Counter  Name: 

Record  5 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  5 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  5 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

"Record  5"  ID:  "Record  5" 

Record 

BasicProcess 

None 


Attribute  Name:  SimTime 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Counter  Name: 

Record  6 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  6 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  6 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

"Record  6"  ID:  "Record  6" 

Record 

BasicProcess 

None 


Attribute  Name:  SimTime 


863 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Record  7"  ID:  "Record  7" 

Record 

BasicProcess 

None 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  7 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  7 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  7 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Record  8"  ID:  "Record  8" 

Record 

BasicProcess 

None 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  8 

Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  8 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  8 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Record  9"  ID:  "Record  9" 

Record 

BasicProcess 

None 


Attribute  Name: 

SimTime 

Counter  Name: 

Record  9 
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Counter  Set  Name: 

Counter  Set  1 

Name: 

Record  9 

Record  into  Set 

No 

Set  Index: 

1 

Tally  Name: 

Record  9 

Tally  Set  Name: 

Tally  Set  1 

Type: 

Interval 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Record  CCD"  ID:  "Assign  27" 

Assign 

BasicProcess 

None 


Name: 


Record  CCD 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Record  CPD"  ID:  "Assign  84" 
Assign 

BasicProcess 

None 


Name: 


Record  CPD 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Record  ICDtime"  ID:  "Assign  11" 

Assign 

BasicProcess 

None 


Name: 


Record  ICD  time 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Reinsert  into  Acquisition  Process  A"  ID:  "Assign  132" 

Assign 

BasicProcess 

None 


Name: 


Reinsert  into  Acquisition  Process  A 


Module  "Reinsert  into  Acquisition  Process  B"  ID:  "Assign  134" 

Type:  Assign 

From  template:  BasicProcess 

Module  Description:  None 
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Operands: 


Name: 


Reinsert  into  Acquisition  Process  B 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Reinsert  into  Acquisition  Process  C"  ID:  "Assign  133" 

Assign 

BasicProcess 

None 


Name: 


Reinsert  into  Acquisition  Process  C 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


If: 

Entity  Type 

Is: 

>= 

Name: 

Rejection  outright 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

55 

Row: 

1 

Type: 

With 

Value: 

1 

"Rejection  outright"  ID:  "Decide  3" 

Decide 

BasicProcess 

None 


Column: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Release  KPPs  to  Acquisition  PreC"  ID:  "Assign  127" 

Assign 

BasicProcess 

None 


Name: 


Release  KPPs  to  Acquisition  PreC 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Request  for  Funds  between  August  and  December"  ID:  "Decide  10" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 
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Is: 

>= 

Name: 

Request  for  Funds  between  August  and  December 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

70 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Requires  AoA  not  ICD"  ID:  "Assign  138" 

Assign 

BasicProcess 

None 


Name: 


Requires  AoA  not  ICD 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

Tran 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

12 

Minimum: 

3 

Name: 

Route  to  Advanced  Concepts 

Priority: 

1 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

7.5 

"Route  to  Advanced  Concepts"  ID:  "Process  10" 

Process 

BasicProcess 

None 


Action: 


D 


Module  "Route  to  Proper  Organization"  ID:  "Process  2" 

Type:  Process 
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From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 


BasicProcess 

None 


Action: 

D 

Allocation: 

Tran 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

7 

Minimum: 

3 

Name: 

Route  to  Proper  Organization 

Priority: 

1 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

3 

"SRR  rework  and  delay"  ID:  "Process  171" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

180 

Minimum: 

60 

Name: 

SRR  rework  and  delay 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

160 

"SVR  rework  and  delay"  ID:  "Process  245" 
Process 
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From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 


BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Expression 

Expression: 

SVR  rework 

Maximum: 

180 

Minimum: 

30 

Name: 

SVR  rework  and  delay 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

160 

"Scope  Growth  Technical  Problems  PreB"  ID:  "Decide  132" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Scope  Growth  Technical  Problems  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

20 

Row: 

1 

Type: 

With 

Value: 

1 

"Scope  Growth  Technical  Problems  PreC"  ID:  "Decide  194" 

Decide 

BasicProcess 

None 
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Operands: 


Column: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 


If: 

Entity  Type 

Is: 

>= 

Name: 

Scope  Growth  Technical  Problems  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

20 

Row: 

1 

Type: 

With 

Value: 

1 

"Scope  and  Award  System  Design  and  Development  Contracts"  ID:  "Process 
230" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

120 

Minimum: 

30 

Name: 

Scope  and  Award  System  Design  and  Development 

Contracts 

Priority: 

2 

Report 

Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

100 

"Scope  and  Award  Technology  Development  Contracts"  ID:  "Process  147" 

Process 

BasicProcess 

None 
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Operands: 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

120 

Minimum: 

30 

Name: 

Scope  and  Award  Technology  Development  Contracts 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

100 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Second  split  into  costing  activities  PreB"  ID:  "Separate  17" 

Separate 

BasicProcess 

None 


#  of  Duplicates: 

1 

Member  Attributes: 

Retain  Original  Entity  Values 

Name: 

Second  split  into  costing  activities  PreB 

Percent  Cost  to  Duplicates 

0 

Type: 

Duplicate 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Second  split  into  costing  activities  PreC"  ID:  "Separate  25" 

Separate 

BasicProcess 

None 


#  of  Duplicates: 

1 

Member  Attributes: 

Retain  Original  Entity  Values 

Name: 

Second  split  into  costing  activities  PreC 

Percent  Cost  to  Duplicates 

0 

Type: 

Duplicate 

Module  "Seek  funds  PreB"  ID:  "Decide  122" 

Type:  Decide 
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BasicProcess 

None 


From  template: 
Module  Description: 
Operands: 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Seek  funds  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

30 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Seek  funds  PreC"  ID:  "Decide  190" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Seek  funds  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

30 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Separate  activities  once  preA"  ID:  "Separate  4" 

Separate 

BasicProcess 

None 


#  of  Duplicates: 

1 

Member  Attributes: 

Retain  Original  Entity  Values 
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Name: 

Separate  activities  once  preA 

Percent  Cost  to  Duplicates 

0 

Type: 

Duplicate 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Separate  activities  once  preB"  ID:  "Separate  9" 

Separate 

BasicProcess 

None 


#  of  Duplicates: 

1 

Member  Attributes: 

Retain  Original  Entity  Values 

Name: 

Separate  activities  once  preB 

Percent  Cost  to  Duplicates 

0 

Type: 

Duplicate 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Separate  activities  once  preC"  ID:  "Separate  21" 

Separate 

BasicProcess 

None 


#  of  Duplicates: 

1 

Member  Attributes: 

Retain  Original  Entity  Values 

Name: 

Separate  activities  once  preC 

Percent  Cost  to  Duplicates 

0 

Type: 

Duplicate 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Separate  again  preA"  ID:  "Separate  5" 

Separate 

BasicProcess 

None 


#  of  Duplicates: 

1 

Member  Attributes: 

Retain  Original  Entity  Values 

Name: 

Separate  again  preA 

Percent  Cost  to  Duplicates 

0 

Type: 

Duplicate 

Module  "Separate  for  logic  testing  PreB"  ID:  "Separate  12" 

Type:  Separate 
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From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


BasicProcess 

None 


#  of  Duplicates: 

1 

Member  Attributes: 

Retain  Original  Entity  Values 

Name: 

Separate  for  logic  testing  PreB 

Percent  Cost  to  Duplicates 

0 

Type: 

Duplicate 

"Separate  for  logic  testing  PreC"  ID:  "Separate  23" 

Separate 

BasicProcess 

None 


#  of  Duplicates: 

1 

Member  Attributes: 

Retain  Original  Entity  Values 

Name: 

Separate  for  logic  testing  PreC 

Percent  Cost  to  Duplicates 

0 

Type: 

Duplicate 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

Set  ACAT  level 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Submodel 

Units: 

Hours 

Value 

1 

"Set  ACAT  level"  ID:  "Process  17" 

Process 

BasicProcess 

None 


Action: 


D 
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Submodel  for  Module  Set  ACAT  level 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"ACAT  IAC"  ID:  "Assign  6" 
Assign 

BasicProcess 


None 


Name: 


ACAT  IAC 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"ACAT  1AM"  ID:  "Assign  7" 

Assign 

BasicProcess 


None 


Name: 


ACAT  1AM 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"ACAT  1C"  ID:  "Assign  8" 
Assign 

BasicProcess 

None 


Name: 


ACAT  1C 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"ACAT  ID"  ID:  "Assign  9" 

Assign 

BasicProcess 

None 


Name: 


ACAT  ID 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"ACAT  II"  ID:  "Assign  5" 

Assign 

BasicProcess 

None 


Name: 


ACAT  II 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"ACAT  III"  ID:  "Assign  4" 

Assign 

BasicProcess 

None 


Name: 


ACAT  III 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


If: 

Entity  Type 

Is: 

>= 

Name: 

Determine  ACAT  level  1 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

50 

Row: 

1 

Type: 

NWith 

Value: 

1 

"Determine  ACAT  level  1"  ID:  "Decide  17" 

Decide 

BasicProcess 

None 


Column: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

30 

Minimum: 

10 

Name: 

Set  Acquisition  Program  Baseline  PreB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

25 

"Set  Acquisition  Program  Baseline  PreB"  ID:  "Process  176" 

Process 

BasicProcess 

None 


Action: 


D 


Module 


"Set  Acquisition  Program  Baseline  PreC"  ID:  "Process  250" 
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Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

30 

Minimum: 

10 

Name: 

Set  Acquisition  Program  Baseline  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

25 

Process 

BasicProcess 

None 


Action: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Set  AoA  Flag"  ID:  "Assign  14" 

Assign 

BasicProcess 

None 


Name: 


Set  AoA 


Flag 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Set  AoA  kill  flag"  ID:  "Assign  15" 

Assign 

BasicProcess 

None 


Name: 


Set  AoA  kill  flag 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Set  Contract  Start  variable"  ID:  "Assign  70" 
Assign 

BasicProcess 

None 


Name: 


Set  Contract  Start  variable 


Module  "Set  Contract  Start  variable  PreC"  ID:  "Assign  105" 
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Type: 

From  template: 
Module  Description: 
Operands: 


Assign 

BasicProcess 

None 


Name: 


Set  Contract  Start  variable  PreC 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Set  Contractor  loop  variable  preC"  ID:  "Assign  98" 
Assign 

BasicProcess 

None 


Name: 


Set  Contractor  loop  variable  preC 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Set  SVR  delay  cost  and  schedule  penalties"  ID:  "Assign  125" 

Assign 

BasicProcess 

None 


Name: 


Set  SVR  delay  cost  and  schedule  penalties 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Set  SVR  rework"  ID:  "Assign  126" 

Assign 

BasicProcess 

None 


Name: 


Set  SVR  rework 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Set  check  on  decision  variable"  ID:  "Assign  24" 

Assign 

BasicProcess 

None 


Name: 


Set  check  on  decision  variable 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Set  check  on  decision  variable  PreC"  ID:  "Assign  80" 

Assign 

BasicProcess 

None 


Name: 


Set  check  on  decision  variable  PreC 


Module  "Set  cost  and  schedule  penalties"  ID:  "Assign  42" 

Type:  Assign 
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From  template: 
Module  Description: 
Operands: 


BasicProcess 

None 


Name: 


Set  cost  and  schedule  penalties 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Set  cost  and  schedule  penalties  PreC"  ID:  "Assign  94" 

Assign 

BasicProcess 

None 


Name: 


Set  cost  and  schedule  penalties  PreC 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Set  path  counter"  ID:  "Assign  17" 
Assign 

BasicProcess 

None 


Name: 


Set  path  counter 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

65 

Minimum: 

30 

Name: 

Source  selection  plans  preA 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

60 

"Source  selection  plans  preA"  ID:  "Process  75" 

Process 

BasicProcess 

None 


Action: 


D 


Module  "Source  selection  plans  preB"  ID:  "Process  142" 

Type:  Process 
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From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 


BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

65 

Minimum: 

30 

Name: 

Source  selection  plans  preB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

60 

"Source  selection  plans  preC"  ID:  "Process  225" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

65 

Minimum: 

30 

Name: 

Source  selection  plans  preC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

60 

"Split  flow  PreB"  ID:  "Separate  11" 
Separate 
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From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


BasicProcess 

None 


#  of  Duplicates: 

1 

Member  Attributes: 

Retain  Original  Entity  Values 

Name: 

Split  flow  PreB 

Percent  Cost  to  Duplicates 

0 

Type: 

Duplicate 

"Split  flow  PreC"  ID:  "Separate  22" 

Separate 

BasicProcess 

None 


#  of  Duplicates: 

1 

Member  Attributes: 

Retain  Original  Entity  Values 

Name: 

Split  flow  PreC 

Percent  Cost  to  Duplicates 

0 

Type: 

Duplicate 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Split  flow  for  PreMS  C"  ID:  "Separate  20" 

Separate 

BasicProcess 

None 


#  of  Duplicates: 

1 

Member  Attributes: 

Retain  Original  Entity  Values 

Name: 

Split  flow  for  PreMS  C 

Percent  Cost  to  Duplicates 

0 

Type: 

Duplicate 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Split  flow  for  PreMSB"  ID:  "Separate  6" 

Separate 

BasicProcess 

None 


#  of  Duplicates: 

1 

Member  Attributes: 

Retain  Original  Entity  Values 

Name: 

Split  flow  for  PreMSB 

Percent  Cost  to  Duplicates 

0 
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Type: 


Duplicate 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Split  into  Acq  Planning  and  Costing  Activities"  ID:  "Separate  19" 

Separate 

BasicProcess 

None 


#  of  Duplicates: 

1 

Member  Attributes: 

Retain  Original  Entity  Values 

Name: 

Split  into  Acq  Planning  and  Costing  Activities 

Percent  Cost  to  Duplicates 

0 

Type: 

Duplicate 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Split  into  Acq  Planning  and  Costing  Activities  PreC"  ID:  "Separate  27" 

Separate 

BasicProcess 

None 


#  of  Duplicates: 

1 

Member  Attributes: 

Retain  Original  Entity  Values 

Name: 

Split  into  Acq  Planning  and  Costing  Activities 

PreC 

Percent  Cost  to 

Duplicates 

0 

Type: 

Duplicate 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Split  into  costing  activities  PreB"  ID:  "Separate  16" 

Separate 

BasicProcess 

None 


#  of  Duplicates: 

1 

Member  Attributes: 

Retain  Original  Entity  Values 

Name: 

Split  into  costing  activities  PreB 

Percent  Cost  to  Duplicates 

0 

Type: 

Duplicate 

"Split  into  costing  activities  PreC"  ID:  "Separate  24" 

Separate 

BasicProcess 


Module 

Type: 

From  template: 
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Module  Description: 
Operands: 


None 


#  of  Duplicates: 

1 

Member  Attributes: 

Retain  Original  Entity  Values 

Name: 

Split  into  costing  activities  PreC 

Percent  Cost  to  Duplicates 

0 

Type: 

Duplicate 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Start  model"  ID:  "Create  1" 

Create 

BasicProcess 

None 


Entities  per  Arrival: 

1 

Entity  Type: 

Idea 

Expression: 

UNIF(  Min,  Max) 

First  Creation: 

0 

Max  Arrivals: 

1 

Name: 

Start  model 

Schedule  Name: 

Schedule  1 

Type: 

Random 

Units: 

Days 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Start  time  check"  ID:  "Assign  19" 

Assign 

BasicProcess 

None 


Name: 


Start  time  check 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Study  for  ICD  Development"  ID:  "Process  13" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 
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Maximum: 

360 

Minimum: 

180 

Name: 

Study  for  ICD  Development 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Submodel 

Units: 

Days 

Value 

300 

Submodel  for  Module  Study  for  ICD  Development 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


If: 

Variable 

Is: 

== 

Name: 

Determine  path 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

ACAT  Level 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

1 

"Determine  path"  ID:  "Decide  20" 

Decide 

BasicProcess 

None 


Column: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Longer  Study" ID: "Process  20" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 
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Expression: 

1 

Maximum: 

360 

Minimum: 

180 

Name: 

Longer  Study 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

300 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

7 

Minimum: 

1 

Name: 

Short  study 

Priority: 

2 

Report  Statistics 

Yes 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

5 

"Short  study"  ID:  "Process  21" 

Process 

BasicProcess 

None 


Action: 


D 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"System  Performance  Specification  delivery"  ID:  "Assign  54" 
Assign 

BasicProcess 

None 


Name: 


System  Performance  Specification  delivery 


Module 


"System  Requirements  Review"  ID:  "Decide  143" 
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Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

System  Requirements  Review 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

35 

Row: 

1 

Type: 

With 

Value: 

1 

"System  Verification  Review"  ID:  "Decide  204" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

System  Verification  Review 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

85 

Row: 

1 

Type: 

With 

Value: 

1 

"TRR  Delay  PreC"  ID:  "Process  266" 

Process 

BasicProcess 

None 


Action: 


D 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Allocation: 

VA 

Delay  Type: 

Expression 

Expression: 

TRR  Delay 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

TRR  Delay  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

1 

"Test  Readiness  Review"  ID:  "Decide  220" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Test  Readiness  Review 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

70 

Row: 

1 

Type: 

With 

Value: 

1 

"Timing  of  funds  OK?"  ID:  "Decide  207" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Name: 

Timing  of  funds  OK? 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

55 

Row: 

1 

Type: 

With 

Value: 

1 

"Trades  Delay  PreC"  ID:  "Process  268" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Expression 

Expression: 

Trades  Delay 

Maximum: 

1.5 

Minimum: 

.5 

Name: 

Trades  Delay  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

1 

"Trades  Needed"  ID:  "Decide  140" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Trades  Needed 

Named: 

Attribute  1 
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Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

70 

Row: 

1 

Type: 

With 

Value: 

1 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Trigger  Acquisition  swimlane  activity"  ID:  "Separate  2" 

Separate 

BasicProcess 

None 


#  of  Duplicates: 

1 

Member  Attributes: 

All 

Name: 

Trigger  Acquisition  swimlane  activity 

Percent  Cost  to  Duplicates 

0 

Type: 

Duplicate 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Trigger  CDR  once"  ID:  "Decide  210" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Trigger  CDR  once 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

CDR 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

0 

Module 

Type: 

From  template: 


"Trigger  PDR  once"  ID:  "Decide  208" 

Decide 

BasicProcess 
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None 


Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

Trigger  PDR  once 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

PDR 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

0 

"Uncertainty  generator  for  Event  Happens  PreB"  ID:  "Create  5" 

Create 

BasicProcess 

None 


Entities  per  Arrival: 

1 

Entity  Type: 

Event  Happens 

Expression: 

TRIA(  30, 60,90) 

First  Creation: 

0 

Max  Arrivals: 

Infinite 

Name: 

Uncertainty  generator  for  Event  Happens  PreB 

Schedule  Name: 

Schedule  1 

Type: 

Expression 

Units: 

Days 

Value: 

1 

"Uncertainty  generator  for  Event  Happens  PreC"  ID:  "Create  7" 

Create 

BasicProcess 

None 


Entities  per  Arrival: 

1 

Entity  Type: 

Event  Happens  2 

Expression: 

TRIA(  30, 60,90) 

First  Creation: 

0 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Max  Arrivals: 

Infinite 

Name: 

Uncertainty  generator  for  Event  Happens  PreC 

Schedule  Name: 

Schedule  1 

Type: 

Expression 

Units: 

Days 

Value: 

1 

"Update  Briefing  Materials"  ID:  "Process  16" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

40 

Minimum: 

10 

Name: 

Update  Briefing  Materials 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

35 

"Update  Briefing  Materials  PreB"  ID:  "Process  89" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

40 

Minimum: 

10 

Name: 

Update  Briefing  Materials  PreB 

891 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

35 

"Update  Briefing  Materials  PreC"  ID:  "Process  183" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

40 

Minimum: 

10 

Name: 

Update  Briefing  Materials  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

35 

"Update  and  Schedule  Calendar"  ID:  "Process  14" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

15 

Minimum: 

3 

Name: 

Update  and  Schedule  Calendar 

892 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

12 

"Update  and  Schedule  Calendar  PreB"  ID:  "Process  87" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

15 

Minimum: 

3 

Name: 

Update  and  Schedule  Calendar  PreB 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

12 

"Update  and  Schedule  Calendar  PreC"  ID:  "Process  181" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

15 

Minimum: 

3 

Name: 

Update  and  Schedule  Calendar  PreC 

893 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

12 

"Wait  for  AoA  Start"  ID:  "Hold  21" 
Hold 

AdvancedProcess 

None 


Attribute: 

Attribute  1 

Condition: 

Start  AoA  flag  ==  1 

Expression: 

| - 

Limit: 

Name: 

Wait  for  AoA  Start 

Queue  Name: 

Wait  for  AoA  Start. Queue 

Queue  Type: 

Queue 

Queue  Type: 

Queue 

Set  Index: 

1 

Set  Name: 

Wait  for  AoA  Start  Set. Queue 

Type: 

Scan 

Wait  for  Value: 

1 

"Wait  for  Baseline  set  PreC"  ID:  "Hold  20" 
Hold 

AdvancedProcess 

None 


Attribute: 

Attribute  1 

Condition: 

PreC  Baseline==l 

Expression: 

Limit: 

Name: 

Wait  for  Baseline  set  PreC 

Queue  Name: 

Wait  for  Baseline  set  PreC. Queue 

Queue  Type: 

Queue 

Queue  Type: 

Queue 

894 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Set  Index: 

1 

Set  Name: 

Wait  for  Baseline  set  PreC  Set. Queue 

Type: 

Scan 

Wait  for  Value: 

1 

"Wait  for  CDR"  ID:  "Hold  19" 
Hold 

AdvancedProcess 

None 


Attribute: 

Attribute  1 

Condition: 

CDR==1 

Expression: 

Limit: 

Name: 

Wait  for  CDR 

Queue  Name: 

Wait  for  CDR. Queue 

Queue  Type: 

Queue 

Queue  Type: 

Queue 

Set  Index: 

1 

Set  Name: 

Wait  for  CDR  Set. Queue 

Type: 

Scan 

Wait  for  Value: 

1 

"Wait  for  EOA  completion"  ID:  "Hold  2" 
Hold 

AdvancedProcess 

None 


Attribute: 

Attribute  1 

Condition: 

EOA  Success==l 

Expression: 

Limit: 

Name: 

Wait  for  EOA  completion 

Queue  Name: 

Wait  for  EOA  completion. Queue 

Queue  Type: 

Queue 

Queue  Type: 

Queue 

Set  Index: 

1 

Set  Name: 

Wait  for  EOA  completion  Set. Queue 
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Type: 

Scan 

Wait  for  Value: 

3 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Wait  for  PDR"  ID:  "Hold  13" 
Hold 

AdvancedProcess 

None 


Attribute: 

Attribute  1 

Condition: 

PDR==1 

Expression: 

Limit: 

Name: 

Wait  for  PDR 

Queue  Name: 

Wait  for  PDR. Queue 

Queue  Type: 

Queue 

Queue  Type: 

Queue 

Set  Index: 

1 

Set  Name: 

Wait  for  PDR  Set. Queue 

Type: 

Scan 

Wait  for  Value: 

10 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Wait  for  RFP  Coord  Process  to  end"  ID:  "Batch  20" 
Batch 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Batch  Size: 

2 

Name: 

Wait  for  RFP  Coord  Process  to  end 

Representative  Entity  Type: 

Rule: 

Any  Entity 

Save  Criterion: 

Last 

Type: 

Permanent 

Module 

Type: 

From  template: 
Module  Description: 


"Wait  for  Signal  from  Acquisition"  ID:  "Hold  1" 
Hold 

AdvancedProcess 

None 


896 


Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Attribute: 

Attribute  1 

Condition: 

contract  start==l 

Expression: 

Limit: 

Name: 

Wait  for  Signal  from  Acquisition 

Queue  Name: 

Wait  for  Signal  from  Acquisition. Queue 

Queue  Type: 

Queue 

Queue  Type: 

Internal 

Set  Index: 

1 

Set  Name: 

Wait  for  Signal  from  Acquisition  Set. Queue 

Type: 

Scan 

Wait  for  Value: 

1 

"Wait  for  Signal  from  Acquisition  PreC"  ID:  "Hold  9" 
Hold 

AdvancedProcess 

None 


Attribute: 

Attribute  1 

Condition: 

contract  start  PreC==l 

Expression: 

Limit: 

— 

Name: 

Wait  for  Signal  from  Acquisition  PreC 

Queue  Name: 

Wait  for  Signal  from  Acquisition  PreC. Queue 

Queue  Type: 

Queue 

Queue  Type: 

Internal 

Set  Index: 

1 

Set  Name: 

Wait  for  Signal  from  Acquisition  PreC  Set. Queue 

Type: 

Scan 

Wait  for  Value: 

1 

"Wait  for  T  and  E  Start"  ID:  "Hold  5" 
Hold 

AdvancedProcess 

None 


Attribute: 

Attribute  1 

Condition: 

T  and  E  Start  PreB==l  &&  KPP  Development  signal  PreB  ==  1 
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Expression: 

Limit: 

Name: 

Wait  for  T  and  E  Start 

Queue  Name: 

Wait  for  T  and  E  Start. Queue 

Queue  Type: 

Queue 

Queue  Type: 

Queue 

Set  Index: 

1 

Set  Name: 

Wait  for  T  and  E  Start  Set. Queue 

Type: 

Scan 

Wait  for  Value: 

10 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Wait  for  a  year"  ID:  "Process  59" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

270 

Minimum: 

180 

Name: 

Wait  for  a  year 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

250 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Wait  for  more  favorable  conditions"  ID:  "Process  80" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

898 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Expression: 

1 

Maximum: 

150 

Minimum: 

100 

Name: 

Wait  for  more  favorable  conditions 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

115 

"Wait  for  more  favorable  conditions  PreC"  ID:  "Process  179" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

150 

Minimum: 

100 

Name: 

Wait  for  more  favorable  conditions  PreC 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

115 

"Wait  for  signal  for  Costing  and  Acquisition  Planning  activities  PreB"  ID:  "Hold 
8" 

Hold 

AdvancedProcess 

None 


Attribute: 

Attribute  1 

Condition: 

Acq  Plan  PreB==l 

899 


Expression: 

Limit: 

Name: 

Wait  for  signal  for  Costing  and  Acquisition  Planning  activities 
PreB 

Queue  Name: 

Wait  for  signal  for  Costing  and  Acquisition  Planning  activities 
PreB. Queue 

Queue  Type: 

Queue 

Queue  Type: 

Queue 

Set  Index: 

1 

Set  Name: 

Wait  for  signal  for  Costing  and  Acquisition  Planning  activities 
PreB  Set. Queue 

Type: 

Scan 

Wait  for 

Value: 

30 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"Wait  for  signal  for  Costing  and  Acquisition  Planning  activities  PreC"  ID:  "Hold 
15" 

Hold 


AdvancedProcess 

None 


Attribute: 

Attribute  1 

Condition: 

Acq  Plan  PreC==l 

Expression: 

Limit: 

Name: 

Wait  for  signal  for  Costing  and  Acquisition  Planning  activities 
PreC 

Queue  Name: 

Wait  for  signal  for  Costing  and  Acquisition  Planning  activities 
PreC. Queue 

Queue  Type: 

Queue 

Queue  Type: 

Queue 

Set  Index: 

1 

Set  Name: 

Wait  for  signal  for  Costing  and  Acquisition  Planning  activities 
PreC  Set.Queue 

Type: 

Scan 

Wait  for 

Value: 

30 

Module 


"Wait  until  both  complete  preA"  ID:  "Batch  2" 
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Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Batch 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Batch  Size: 

2 

Name: 

Wait  until  both  complete  preA 

Representative  Entity  Type: 

Rule: 

Any  Entity 

Save  Criterion: 

Last 

Type: 

Permanent 

"Wait  until  next  year"  ID:  "Process  12" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

NVA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

270 

Minimum: 

180 

Name: 

Wait  until  next  year 

Priority: 

2 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

250 

"Waiting  Period"  ID:  "Process  9" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Expression: 

1 

Maximum: 

180 

Minimum: 

14 

Name: 

Waiting  Period 

Priority: 

1 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

118 

"Which  Milestone  after  MDAP  threshold?"  ID:  "Decide  7" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Which  Milestone  after  MDAP  threshold? 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

50 

Row: 

1 

Type: 

NWith 

Value: 

1 

"Which  Milestone?"  ID:  "Decide  5" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Entity  Type 

Is: 

>= 

Name: 

Which  Milestone? 

Named: 

Attribute  1 

902 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Named: 

Entity  1 

Named: 

Variable  1 

Percent  True 

50 

Row: 

1 

Type: 

NWith 

Value: 

1 

"contractor  loop  PreB"  ID:  "Decide  137" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

contractor  loop  PreB 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

contractor  loop 

Percent  True 

50 

Row: 

1 

Type: 

If 

Value: 

0 

"contractor  loop  check  PreC"  ID:  "Decide  199" 

Decide 

BasicProcess 

None 


Column: 

1 

If: 

Variable 

Is: 

== 

Name: 

contractor  loop  check  PreC 

Named: 

Attribute  1 

Named: 

Entity  1 

Named: 

contractor  loop  PreC 

Percent  True 

50 

Row: 

1 
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Type: 

If 

Value: 

0 

Module 

Type: 

From  template: 

Module  Description: 

"determine  good  funding  quality  preB"  ID:  "Assign  43" 

Assign 

BasicProcess 

None 

Operands: 

Name:  determine  good  funding  quality  preB 

Module 

"determine  good  funding  quality  preC"  ID:  "Assign  95" 

Type: 

Assign 

From  template: 

BasicProcess 

Module  Description: 

None 

Operands: 

Name:  determine  good  funding  quality  preC 

Module 

"determine  poor  funding  quality  preB"  ID:  "Assign  44" 

Type: 

Assign 

From  template: 

BasicProcess 

Module  Description: 

None 

Operands: 

Name:  determine  poor  funding  quality  preB 

Module 

"determine  poor  funding  quality  preC"  ID:  "Assign  96" 

Type: 

Assign 

From  template: 

BasicProcess 

Module  Description: 

None 

Operands: 

Name:  determine  poor  funding  quality  preC 

Module 

"end  simulation  PreB"  ID:  "Assign  23" 

Type: 

Assign 

From  template: 

BasicProcess 

Module  Description: 

None 

Operands: 

Name:  end  simulation  PreB 

Module 

"end  simulation  PreC"  ID:  "Assign  79" 

Type: 

Assign 

From  template: 

BasicProcess 

Module  Description: 

None 
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Operands: 


Name: 


end  simulation  PreC 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"for  Affordability  Assessment  PreB"  ID:  "Batch  13" 
Batch 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Batch  Size: 

3 

Name: 

for  Affordability  Assessment  PreB 

Representative  Entity  Type: 

Rule: 

Any  Entity 

Save  Criterion: 

Last 

Type: 

Permanent 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"for  Affordability  Assessment  PreC"  ID:  "Batch  18" 
Batch 

BasicProcess 

None 


Attribute  Name: 

Attribute  1 

Batch  Size: 

3 

Name: 

for  Affordability  Assessment  PreC 

Representative  Entity  Type: 

Rule: 

Any  Entity 

Save  Criterion: 

Last 

Type: 

Permanent 

Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"for  funding  check"  ID:  "Separate  18" 

Separate 

BasicProcess 

None 


#  of  Duplicates: 

1 

Member  Attributes: 

Retain  Original  Entity  Values 

Name: 

for  funding  check 

Percent  Cost  to  Duplicates 

0 

Type: 

Duplicate 
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Module 

Type: 

From  template: 
Module  Description: 
Operands: 


Module 

Type: 

From  template: 
Module  Description: 
Operands: 


"for  funding  check  PreC"  ID 

Separate 

BasicProcess 

None 

"Separate  26" 

#  of  Duplicates: 

1 

Member  Attributes: 

Retain  Original  Entity  Values 

Name: 

for  funding  check  PreC 

Percent  Cost  to  Duplicates 

0 

Type: 

Duplicate 

"to  Acquisition  Modernization  or  Sustainment  Activity"  ID:  "Process  4" 

Process 

BasicProcess 

None 


Action: 

D 

Allocation: 

VA 

Delay  Type: 

Triangular 

Expression: 

1 

Maximum: 

1460 

Minimum: 

180 

Name: 

to  Acquisition  Modernization  or  Sustainment  Activity 

Priority: 

1 

Report  Statistics 

No 

Std  Dev: 

.2 

Type: 

Standard 

Units: 

Days 

Value 

903 

906 


